<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">HI all:<br>OO C is C++ in theory not in practice, could be better than this, but we should not do so and don't look a Modula-3 type system that preserves under compilation that's an abstract machine that interacts with whatever machine code generator is (M3CG) compiled to for whatever language you would like?<br>That's why I insist the original acronym of M3CG(M2CG) is Machine Code Generator, this is not a translator, nor anything else, it was created for the purpose of compiling and linking compiler intermediate language, nothing else.<br><br>Besides many languages and tongues I guess is better to speak clearly in a universal machine like Baby Modula-3, choosing Modula-3 as mother tongue, that is we need to speak in Modula-3 from Baby and counter wise.<br><br>As some TV add said: "the problem is simple the answer it's not"<br>So I would try to explain
meaningfully clearly, we need to understand how to encode Modula-3 (1989) in a language like Quest (1994) in terms of Baby Modula-3 (1993), that is Target is BM3, Host is Quest, and Source is Modula-3.<br><br>It turns out that doing type inference in terms of Quest is decidable, but in terms of Baby Modula-3 I don't know, it's pretty much a question of the million, the problem for real is can we encode Modula-3 in Baby Modula-3? That's a good question for the people who advocate for not so obscure language definition (It has some examples of understanding the language in terms of a exception key concept, but not in object terms)<br><br>So, what is next is to find a theory of Objects, there are people that is not happy with Cardelli's definition and I agree with them we should we looking at the problem concretely with options I know of different kinds of options, but you would not like to hear the one I prefer is likely to be undecidable and inconsistent
terms, so we could argue about obscurity of language definition again (right ?).<br><br>This option is called pebble is a language written by Butler Lampson (Modula-2+ author) and Rodney Burstall (a aforementioned computer theorist ).<br><br>In some sense Pebble is just about to talk about Modula-3 Module system, but it would need a lot of research to put it on place for being chosen.<br>Thanks in advance<br><br>--- El <b>jue, 16/8/12, Jay K <i><jay.krell@cornell.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: Jay K <jay.krell@cornell.edu><br>Asunto: [M3devel] higher level m3cg?<br>Para: "m3devel" <m3devel@elegosoft.com><br>Fecha: jueves, 16 de agosto, 2012 09:21<br><br><div id="yiv2015490471">
<style><!--
#yiv2015490471 .yiv2015490471hmmessage P
{
margin:0px;padding:0px;}
#yiv2015490471 body.yiv2015490471hmmessage
{
font-size:12pt;font-family:Calibri;}
--></style><div><div dir="ltr">Should m3cg provide enough information for a backend to generate idiomatic C?<br>(What is idiomatic C? e.g. I'm ignoring loop constructs and exception handlinh..)<br><br><br>Should we make it so?<br><br><br>Or be pragmatic and see if anyone gets to that point?<br><br><br>But, look at this another way.<br>Let's say we are keeping the gcc backend.<br><br><br>Isn't it reasonable to have a better experience with stock gdb?<br><br><br>What should m3cg look like then?<br><br><br>Matching up m3front to gcc turns out to be "wierd".<br>As does having a backend generate "C".<br><br><br>In particular, "wierd" because there is a "level mismatch".<br><br><br>m3cg presents a fairly low level view of the program.<br> It does layout. Global variables are stuffed into what you might call a "struct", with<br>no assigned field names. Field references are done by adding to addresses and casting.<br><br><br>Too low level to provide a
"good" gcc tree representation or to generate "normal" C.<br><br><br>One might be able to, by somewhat extraordinary means, make due.<br>That is, specifically one could deduce field references from<br>offsets/sizes. But maybe it is reasonable for load/store<br>to include fields? Maybe in addition to what it provides?<br><br><br>As well, it appears to me, that<br><br><br>given TYPE Enum = {One, Two, Three};<br><br>the m3cg is like:<br><br>declare enum typeidblah<br>declare enum_elt One<br>declare enum_elt Two<br>declare enum_elt Three<br>declare_typename typeidblah Enum<br><br><br>One kind of instead wants more like:<br><br><br>declare enum typeidblah Enum<br>declare enum_elt One => rename it Enum_One<br>declare enum_elt Two ""<br>declare enum_elt Three ""<br><br><br>However I understand that {One, Two, Three} exists<br>as anonymous type independent of the name "Enum".<br><br><br>One could just as well have:<br>given TYPE Enum1 = {One, Two,
Three};<br>given TYPE Enum2 = {One, Two, Three};<br><br><br>Enum1 and Enum2 probably have the same typeid, and are just<br>two typenames for the same type.<br><br><br>likewise:<br>given TYPE Enum1 = {One, Two, Three};<br>given TYPE Enum2 = Enum1;<br><br><br>but, pragmatically, in the interest of generating better C,<br>can we pass a name along with declare_enum?<br><br>I ask somewhat rhetorically. I realize there is the answer:<br> enum Mtypeid { Mtypeid_One, Mtypeid_Two, Mtypeid_Three };<br> typedef enum Mtypeid Enum1;<br><br><br>Also, enum variables I believe end up as just UINT8, 16, or 32.<br>Loads of enum values I believe end up as just loads of integers.<br>Can we pass along optional enum names with declare_local/declare_param?<br>And optional enum names with load_int?<br>Or add a separate load_enum call?<br><br><br>Really, I understand that the current interface can be pressed to do<br>pretty adequate things. I can infer field
references. The way enums work<br>isn't too bad.<br><br><br> - Jay </div></div>
</div></blockquote></td></tr></table>