[M3devel] higher level m3cg?

[Daniel Alejandro Benavides D.]

HI all:
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?
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.

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.

As some TV add said: "the problem is simple the answer it's not"
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.

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)

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 ?).

This option is called pebble is a language written by Butler Lampson (Modula-2+ author) and Rodney Burstall (a aforementioned computer theorist ).

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.
Thanks in advance

--- El jue, 16/8/12, Jay K <jay.krell at cornell.edu> escribió:

De: Jay K <jay.krell at cornell.edu>
Asunto: [M3devel] higher level m3cg?
Para: "m3devel" <m3devel at elegosoft.com>
Fecha: jueves, 16 de agosto, 2012 09:21



Should m3cg provide enough information for a backend to generate idiomatic C?
(What is idiomatic C? e.g. I'm ignoring loop constructs and exception handlinh..)


Should we make it so?


Or be pragmatic and see if anyone gets to that point?


But, look at this another way.
Let's say we are keeping the gcc backend.


Isn't it reasonable to have a better experience with stock gdb?


What should m3cg look like then?


Matching up m3front to gcc turns out to be "wierd".
As does having a backend generate "C".


In particular, "wierd" because there is a "level mismatch".


m3cg presents a fairly low level view of the program.
  It does layout. Global variables are stuffed into what you might call a "struct", with
no assigned field names. Field references are done by adding to addresses and casting.


Too low level to provide a "good" gcc tree representation or to generate "normal" C.


One might be able to, by somewhat extraordinary means, make due.
That is, specifically one could deduce field references from
offsets/sizes. But maybe it is reasonable for load/store
to include fields? Maybe in addition to what it provides?


As well, it appears to me, that


given TYPE Enum = {One, Two, Three};

the m3cg is like:

declare enum typeidblah
declare enum_elt One
declare enum_elt Two
declare enum_elt Three
declare_typename typeidblah Enum


One kind of instead wants more like:


declare enum typeidblah Enum
declare enum_elt One => rename it Enum_One
declare enum_elt Two ""
declare enum_elt Three ""


However I understand that {One, Two, Three} exists
as anonymous type independent of the name "Enum".


One could just as well have:
given TYPE Enum1 = {One, Two, Three};
given TYPE Enum2 = {One, Two, Three};


Enum1 and Enum2 probably have the same typeid, and are just
two typenames for the same type.


likewise:
given TYPE Enum1 = {One, Two, Three};
given TYPE Enum2 = Enum1;


but, pragmatically, in the interest of generating better C,
can we pass a name along with declare_enum?

I ask somewhat rhetorically. I realize there is the answer:
  enum Mtypeid { Mtypeid_One, Mtypeid_Two, Mtypeid_Three };
  typedef enum Mtypeid Enum1;


Also, enum variables I believe end up as just UINT8, 16, or 32.
Loads of enum values I believe end up as just loads of integers.
Can we pass along optional enum names with declare_local/declare_param?
And optional enum names with load_int?
Or add a separate load_enum call?


Really, I understand that the current interface can be pressed to do
pretty adequate things. I can infer field references. The way enums work
isn't too bad.


 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120816/a757955e/attachment-0002.html>