Re: [DotGNU]Melody

[Marco Manfredini]

Norbert Bollow wrote:
> I believe that the set of supported languages in which you can
> write applications for the DotGNU platform should definately
> include C and C++, and one of the big open questions is how to
> best achieve this.  Compiling (directly or indirectly) to IL
> may or may not be the best strategy.
>

Btw. I fear that M$ messed things hugely up with their
CLR. For example I recently found out, that making a C++ class managed 
(__gc), changes their constructor semantics, i.e. a virtual call during 
base class construction calls the method from the derived object, which 
isn't initialized yet, like in Java and C#. This is dangerous, but 
typical how M$ treats standards: they mistreat them)

I'd bet that direct translation into IL will require more changes to the 
compiler.

>>* Every dotGNU language can compile to Melody.
>>* Every Melody can be compiled into IL.
>>* Every Melody can be compiled into JavaVM.
>>
>
> Why compile Melody to *two* bytecode formats???  Sounds like
> unneccessary effort in terms of compiler code that would need to
> be written and maintained!?
???
This decouples a language compiler from the back-end. It should make 
work simpler indeed, since a new compiler has to support only one 
back-end language (Melody). And the implementor of a translator from 
Melody to something else would not need to fear that he'd break one of 
the supported front-end language, because he has only to follow a 
cleanly defined interface (i.e. an abstract language which has easy 
semantics).

So if we want to support compilation to JavaVM, we write a mapping 
between Melody and Java. If somebody doesn't like the idea to interpret 
bytecodes of wrong endianess on his PDA, he writes a trivial (but space 
efficient) Melody to machine language converter.

This should also encourage the maintainers of languages outside of the 
gcc collection to create a port to a Melody backend. And making a 
Language=>Melody translator should be save a lot of work, because you 
don't have to mud into the low-levelness to a bytecode machine 
(stacklayout etc.) anymore.

The looks like extra work in the first place, since there are many 
existing language ports for Java for example. But how do we get these 
Java Ports to run onto IL? JavaVM code and IL code cannot interoperate 
because they are tied to their language runtime. Or can they?

Greetings, Marco