<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>In the debugger and, I somewhat lied, for the C to somewhat mimic the Modula-3, I'd definitely prefer "A" and "B".<br><br>C++ programmers wrestle with this, but it is widely agreed to be a "quality bug" (correct but not ideal) and ought to be fixed.<br><br><br>If I say:<br>std::string a;<br><br><br>and hover over it in a debugger, I see something ridiculous std::basic_string<...something really long>.<br><br><br>The (Microsoft, at least) compiler was fixed to issue warnings in terms of "used types" instead of "alias bases", but the debuginfo was not.<br><br><br>Enums are likely to end up like:<br><br> enum T1234 { T1234_Red, T1234_Blue, T1234_Green }; <br><br><br>anything given just one typename I have a chance of "fixing" well. But in the face of multiple typenames, an arbitrary one will win.<br>I can go back and replace the text T1234 with "Color" or or "Color_" whatnot..even in the enum members.<br><br><br> - Jay<br><br><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">From: hosking@cs.purdue.edu<br>Date: Wed, 10 Apr 2013 13:43:26 +1000<br>To: jay.krell@cornell.edu<br>CC: m3devel@elegosoft.com<br>Subject: Re: [M3devel] typenames vs. typeids in M3CG?<br><br>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="ecxApple-interchange-newline"><blockquote><div class="ecxhmmessage" 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;"><div dir="ltr">Given something like:<br> <br><br> TYPE A = RECORD ... END; (* typeid 123456 *) <span class="ecxApple-converted-space"> </span><br> TYPE B = A; <span class="ecxApple-converted-space"> </span><br> <br> <span class="ecxApple-converted-space"> </span><br> VAR a:A; <span class="ecxApple-converted-space"> </span><br> VAR b:B; <span class="ecxApple-converted-space"> </span><br> <br><br> <br> ideally the generated code looks like: <span class="ecxApple-converted-space"> </span><br> <br> <br> struct T123456; typedef struct T123456 T123456; <span class="ecxApple-converted-space"> </span><br> struct T123456 { ... }; <span class="ecxApple-converted-space"> </span><br> <br> <span class="ecxApple-converted-space"> </span><br> typedef T123456 A; <span class="ecxApple-converted-space"> </span><br> typedef T123456 B; <span class="ecxApple-converted-space"> </span><br> A a; <span class="ecxApple-converted-space"> </span><br> B b; <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> Currently I produce: <span class="ecxApple-converted-space"> </span><br> T123456 a; <span class="ecxApple-converted-space"> </span><br> T123456 b; <span class="ecxApple-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="ecxApple-converted-space"> </span><br> B a; <span class="ecxApple-converted-space"> </span><br> B b; <span class="ecxApple-converted-space"> </span><br><br> However actually producing the ideal/idiomatic: <span class="ecxApple-converted-space"> </span><br> A a; <span class="ecxApple-converted-space"> </span><br> B b; <span class="ecxApple-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="ecxApple-converted-space"> </span><br> Reasonable?<span class="ecxApple-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="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> TYPE Color = {Red, Blue, Green}; <span class="ecxApple-converted-space"> </span><br> <br> <br> The thing to the right is anonymous type with a typeid (structural hash). <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> TYPE Color2 = {Red, Blue, Green}; <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> VAR Color:c; <span class="ecxApple-converted-space"> </span><br> VAR Color2:c2; <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> In gcc and newer Visual C++, the ideal code can use enums with explicit sizes, *roughly*: <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> typedef enum { Red, Blue, Green } Color, Color2; /* importat gcc and Visual C++ extensions omitted */<span class="ecxApple-converted-space"> </span><br><br> <br> Color c; <span class="ecxApple-converted-space"> </span><br> Color2 c2; <span class="ecxApple-converted-space"> </span><br> <br><br> However, again, without frontend help we are faced with probably:<span class="ecxApple-converted-space"> </span><br> T1234 c; <span class="ecxApple-converted-space"> </span><br> T1234 c2; <span class="ecxApple-converted-space"> </span><br><br> or perhaps <span class="ecxApple-converted-space"> </span><br> Color c; <span class="ecxApple-converted-space"> </span><br> Color2 c2; <span class="ecxApple-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="ecxApple-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="ecxApple-converted-space"> </span><br> <br><br> Similarly for opaque types, currently I have:<span class="ecxApple-converted-space"> </span><br> <br><br> typdef char* ADDRESS; <span class="ecxApple-converted-space"> </span><br> TYPE A <: whatever; <span class="ecxApple-converted-space"> </span><br> TYPE B <: whatever; <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> typedef ADDRESS T1234; (* typeid for opaque type *) <span class="ecxApple-converted-space"> </span><br> typedef ADDRESS T123478; (* typeid for opaque type *) <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> T1234 a; <span class="ecxApple-converted-space"> </span><br> T123478 b; <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> This is not particularly readable.<span class="ecxApple-converted-space"> </span><br> It can go either way: <span class="ecxApple-converted-space"> </span><br> ADDRESS a;<br> ADDRESS b;<span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br><br> Or ideally more like:<br> A* a;<br> B* b;<br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> or<span class="ecxApple-converted-space"> </span><br> A a; <span class="ecxApple-converted-space"> </span><br> B b; <span class="ecxApple-converted-space"> </span><br> <br> <br> Opaque types are a larger problem, at least in my head.<span class="ecxApple-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="ecxApple-converted-space"> </span><br> Either the public part or the entire thing. If the information is available. <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-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="ecxApple-converted-space"> </span><br> (The C code has no indentation, no loops, many gotos, redundant temporaries/assignments...)<span class="ecxApple-converted-space"> </span><br> <br> <span class="ecxApple-converted-space"> </span><br> If you have used stock gdb or debugged the NT386 target, you should realize the problem.<span class="ecxApple-converted-space"> </span><br> <span class="ecxApple-converted-space"> </span><br> <br> I believe the frontend should be passing typenames along with typeids for locals/parameters. <span class="ecxApple-converted-space"> </span><br> I'll poke around later. It might not be trivial -- i.e. if the information isn't preserved.<span class="ecxApple-converted-space"> </span><br> Advise?<br> <br> <span class="ecxApple-converted-space"> </span><br> - Jay<br><br></div></div></blockquote></div><br></div></div> </div></body>
</html>