Re: [DotGNU]Melody

[Marco Manfredini]

Mike Hoolehan wrote:
> On (07/08/01 09:47), Marco Manfredini wrote:
>
>>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.
>>
>
> If Melody can be described as a machine-independent intermediate language
> that preserves semantic information about the original code, couldn't it
> also just be described as another programming language?
>

Not if you would call machine-language (not assembler) a programming
language. Melody would be code, in the sense that it consist of binary
tokens which had a unique and non-ambigous meaning. Compare this to C 
where for example the operator + is /polymorphic/ since it works with 
different types, involves coversions etc..its the job of the compiler to 
figure out what "+" means according to the language rules.

It could be converted to a text representation which would reveal that 
the codes in fact describe a structure. This is the difference from 
JavaVM where "structure" exists only in the description of the class, 
but no more in the byte-codes (these are just codes, and you'd have to 
reconstruct block scopes or loop). In that sense, Melody would be a 
structured higher-order machine-code.


> When it's said that all dotGNU supported languages must be translated 
into
> Melody, which can then be translated into perhaps Java Bytecode or IL,
> aren't we really saying that dotGNU only supports the Melody programming
> language and that to use another langauge someone (GNU) will need to 
write a
> translator from the source language to Melody?

No the schema is this:

Lang1 -------\            /------ JavaVM
              |           |
Lang2 --------|           |------- M$-IL      /---- i386-hurd
              |---Melody--|                  /
Lang2 --------|           |------- GCC------------ m68k-linux
              |           |                  \
Lang3 -------/            \------- Y*         \---- mips-elix

Y* are other backends that destiny makes us support. "GCC" means,
that GCC understands Melody-code and translates it into machine-code for
a platform. Lang[1-3] are languages that should run on every platform
that can be generated from Melody.

>
> Sorry to speak in questions, but I'm not sure of my understanding of 
Melody.
>
> dotGNU could just as easily say that Java, for instance, is that
> machine-independent language that preserves semantic info.  Saves the 
work of
> inventing a new language.  I don't truly think this is a good idea, 
by the
> way, just making a point.
>

I think that just JavaVM won't really  alltogether work. The design of 
the JavaVM had Java in mind. It executes what Java describes. This means 
that other languages need to take funny circumventions to implement 
their semantics. For example, Java has no "pointers", it has references 
which *can only* point to class instances.

Now, map C or C++ to JavaVM. Or any other language that has pointers.

Now, write a JIT which can reconstuct the pointer-hacks you've made into
real pointers!

M$-IL is "richer", since it was designed with more languages in mind,
but (as I've said somnewhere before), the CLR requires changes to the
language semantics, which had to be hardcoded into the compiler. Into 
each compiler. But I'm convicted that a intermediate language which 
provides sufficent information about the expression structure could 
provide what the translator to M$-IL would need to support the operation 
of the output under M$-CLR.

> A separate point: if Melody is used, perhaps an xml-based syntax would be
> beneficial.
>

Yes, I think that Melody could have homomorphic representations, the
binary representation would exist for fast machine operation, compressed
  storage and distribution, while structural equivalent XML
representation could be used for high-level queries, database storage,
browsing etc with XML processing tools.

It wouldn't make a difference for the dotGNU tools, because it's just a 
matter of the reader/writer library they'd use. Sensible design 
practice, separate processing from I/O.

Greetings, Marco