[M3devel] typenames vs. typeids in M3CG?

[Jay K]

In the debugger and, I somewhat lied, for the C to somewhat mimic the Modula-3, I'd definitely prefer "A" and "B".

C++ programmers wrestle with this, but it is widely agreed to be a "quality bug" (correct but not ideal) and ought to be fixed.


If I say:
std::string a;


and hover over it in a debugger, I see something ridiculous std::basic_string<...something really long>.


The (Microsoft, at least) compiler was fixed to issue warnings in terms of "used types" instead of "alias bases", but the debuginfo was not.


Enums are likely to end up like:

 enum T1234 { T1234_Red, T1234_Blue, T1234_Green }; 


anything given just one typename I have a chance of "fixing" well. But in the face of multiple typenames, an arbitrary one will win.
I can go back and replace the text T1234 with "Color" or or "Color_" whatnot..even in the enum members.


 - Jay


From: hosking at cs.purdue.edu
Date: Wed, 10 Apr 2013 13:43:26 +1000
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] typenames vs. typeids in M3CG?

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/15ebe9ef/attachment-0002.html>