<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://7530/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I actually prefer the declarations<div><br></div><div>T123456 a;</div><div>T123456 b;</div><div><br></div><div>Type names mean nothing in Modula-3’s structural type system.</div><div><br></div><div><div><div>On Apr 10, 2013, at 12:12 PM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="hmmessage" style="font-size: 12pt; font-family: Calibri; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div dir="ltr">Given something like:<br> <br><br> TYPE A = RECORD ... END; (* typeid 123456 *) <span class="Apple-converted-space"> </span><br> TYPE B = A; <span class="Apple-converted-space"> </span><br> <br> <span class="Apple-converted-space"> </span><br> VAR a:A; <span class="Apple-converted-space"> </span><br> VAR b:B; <span class="Apple-converted-space"> </span><br> <br><br> <br> ideally the generated code looks like: <span class="Apple-converted-space"> </span><br> <br> <br> struct T123456; typedef struct T123456 T123456; <span class="Apple-converted-space"> </span><br> struct T123456 { ... }; <span class="Apple-converted-space"> </span><br> <br> <span class="Apple-converted-space"> </span><br> typedef T123456 A; <span class="Apple-converted-space"> </span><br> typedef T123456 B; <span class="Apple-converted-space"> </span><br> A a; <span class="Apple-converted-space"> </span><br> B b; <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> Currently I produce: <span class="Apple-converted-space"> </span><br> T123456 a; <span class="Apple-converted-space"> </span><br> T123456 b; <span class="Apple-converted-space"> </span><br><br> it is easy to make the first or better yet last typename for any given typeid win, giving us: <span class="Apple-converted-space"> </span><br> B a; <span class="Apple-converted-space"> </span><br> B b; <span class="Apple-converted-space"> </span><br><br> However actually producing the ideal/idiomatic: <span class="Apple-converted-space"> </span><br> A a; <span class="Apple-converted-space"> </span><br> B b; <span class="Apple-converted-space"> </span><br><br> I believe requires frontend/M3CG changes -- to pass an optional typename and not just a typeid for locals/parameters.<span class="Apple-converted-space"> </span><br> Reasonable?<span class="Apple-converted-space"> </span><br> <br> <br> The problem seems worst for records. <br> But it applies to enums, subranges, opaque types. <br> <br><br> Actual source is full of typenames. M3CG is full of typeids. <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> TYPE Color = {Red, Blue, Green}; <span class="Apple-converted-space"> </span><br> <br> <br> The thing to the right is anonymous type with a typeid (structural hash). <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> TYPE Color2 = {Red, Blue, Green}; <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> VAR Color:c; <span class="Apple-converted-space"> </span><br> VAR Color2:c2; <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */<span class="Apple-converted-space"> </span><br><br> <br> Color c; <span class="Apple-converted-space"> </span><br> Color2 c2; <span class="Apple-converted-space"> </span><br> <br><br> However, again, without frontend help we are faced with probably:<span class="Apple-converted-space"> </span><br> T1234 c; <span class="Apple-converted-space"> </span><br> T1234 c2; <span class="Apple-converted-space"> </span><br><br> or perhaps <span class="Apple-converted-space"> </span><br> Color c; <span class="Apple-converted-space"> </span><br> Color2 c2; <span class="Apple-converted-space"> </span><br> <br> <br> Currently I just use one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64 for all enumerations and subranges.<span class="Apple-converted-space"> </span><br> 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.<span class="Apple-converted-space"> </span><br> <br><br> Similarly for opaque types, currently I have:<span class="Apple-converted-space"> </span><br> <br><br> typdef char* ADDRESS; <span class="Apple-converted-space"> </span><br> TYPE A <: whatever; <span class="Apple-converted-space"> </span><br> TYPE B <: whatever; <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> typedef ADDRESS T1234; (* typeid for opaque type *) <span class="Apple-converted-space"> </span><br> typedef ADDRESS T123478; (* typeid for opaque type *) <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> T1234 a; <span class="Apple-converted-space"> </span><br> T123478 b; <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> This is not particularly readable.<span class="Apple-converted-space"> </span><br> It can go either way: <span class="Apple-converted-space"> </span><br> ADDRESS a;<br> ADDRESS b;<span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br><br> Or ideally more like:<br> A* a;<br> B* b;<br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> or<span class="Apple-converted-space"> </span><br> A a; <span class="Apple-converted-space"> </span><br> B b; <span class="Apple-converted-space"> </span><br> <br> <br> Opaque types are a larger problem, at least in my head.<span class="Apple-converted-space"> </span><br> I'd like to have pointers to structs, but I don't yet know how to make that work.<span class="Apple-converted-space"> </span><br> Either the public part or the entire thing. If the information is available. <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> The goal isn't so much to make the C code readable, it is to make what the debugger shows readable.<span class="Apple-converted-space"> </span><br> (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...)<span class="Apple-converted-space"> </span><br> <br> <span class="Apple-converted-space"> </span><br> If you have used stock gdb or debugged the NT386 target, you should realize the problem.<span class="Apple-converted-space"> </span><br> <span class="Apple-converted-space"> </span><br> <br> I believe the frontend should be passing typenames along with typeids for locals/parameters. <span class="Apple-converted-space"> </span><br> I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved.<span class="Apple-converted-space"> </span><br> Advise?<br> <br> <span class="Apple-converted-space"> </span><br> - Jay<br><br></div></div></blockquote></div><br></div></body></html>