[M3devel] typenames vs. typeids in M3CG?

[Tony Hosking]

I actually prefer the declarations

T123456 a;
T123456 b;

Type names mean nothing in Modula-3’s structural type system.

On Apr 10, 2013, at 12:12 PM, Jay K <jay.krell at cornell.edu> wrote:

> Given something like:
>  
> 
>   TYPE A = RECORD ... END; (* typeid 123456 *)   
>   TYPE B = A;  
>     
>    
>   VAR a:A;  
>   VAR b:B;  
>  
> 
>  
>   ideally the generated code looks like:  
>  
>   
>     struct T123456; typedef struct T123456 T123456;  
>     struct T123456 { ... };  
>    
>    
>     typedef T123456 A;      
>     typedef T123456 B;     
>     A a;      
>     B b;      
>   
>   Currently I produce:  
>       T123456 a;   
>       T123456 b;     
> 
>    it is easy to make the first or better yet last typename for any given typeid win, giving us:   
>      B a;   
>      B b;   
> 
>   However actually producing the ideal/idiomatic:  
>     A a;    
>     B b;    
> 
>  I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters. 
>  Reasonable? 
>  
>  
>   The problem seems worst for records.  
>   But it applies to enums, subranges, opaque types. 
>     
> 
>   Actual source is full of typenames. M3CG is full of typeids.  
>   
>   
>   TYPE Color = {Red, Blue, Green};  
>  
>  
>   The thing to the right is anonymous type with a typeid (structural hash).  
>   
>    
>  TYPE Color2 = {Red, Blue, Green};   
>   
>   VAR Color:c;    
>   VAR Color2:c2;   
>   
>   
>   In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*:    
>   
>   typedef enum { Red, Blue, Green } Color, Color2;   /* importat gcc and Visual C++ extensions omitted */ 
> 
>   
>   Color c;    
>   Color2 c2;   
>  
> 
>   However, again, without frontend help we are faced with probably: 
>    T1234 c;  
>    T1234 c2;  
> 
>   or perhaps  
>     Color c;   
>     Color2 c2;   
>  
>  
>   Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges. 
>  That is only the portable way to all C and C++ compilers, but I think it is worthwhile to use gcc and Visual C++ extensions with #ifdef to  do better. Ignoring the problem of what to name types, I can still make the enum member names visible in a debugger. 
>  
> 
>  Similarly for opaque types, currently I have: 
>  
> 
>   typdef char* ADDRESS;  
>   TYPE A <: whatever;  
>   TYPE B <: whatever;  
>   
>   
>   typedef ADDRESS T1234; (* typeid for opaque type *)   
>   typedef ADDRESS T123478; (* typeid for opaque type *)   
>   
>   
>   T1234 a;   
>   T123478 b;   
>    
>     
>  This is not particularly readable. 
>   It can go either way:  
>     ADDRESS a;
>     ADDRESS b; 
>   
> 
>  Or ideally more like:
>     A* a;
>     B* b;
>   
>   
>   or 
>     A a;  
>     B b;  
>  
>  
>  Opaque types are a larger problem, at least in my head. 
>  I'd like to have pointers to structs, but I don't yet know how to make that work. 
>  Either the public part or the entire thing. If the information is available.  
>   
>   
>  The goal isn't so much to make the C code readable, it is to make what the debugger shows readable. 
>   (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...) 
>  
>   
>  If you have used stock gdb or debugged the NT386 target, you should realize the problem. 
>   
>  
>   I believe the frontend should be passing typenames along with typeids for locals/parameters.  
>   I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved. 
>   Advise?
>  
>   
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130410/7119ff90/attachment-0002.html>