[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Melody

From: Marco Manfredini
Subject: Re: [DotGNU]Melody
Date: Tue, 07 Aug 2001 07:22:15 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801

Norbert Bollow wrote:
> Marco Manfredini <address@hidden> wrote:
>>>2. Expand GCC so that it can compile from all its supported
>>>   languages to Melody-based Portable Executables.
> Hmm... if your idea doesn't give us support for running
> applications that are written in C or C++, then my level of
> interest is decreasing rapidly.
Oh..C++ is MY language. I would die if I couldn't code dotGNU in C++.

I think I was too unclear about this. I was about to -nothing- to
say, about gcc-C/C++ due to a lack of competence from my side [about if
gcc can be changed to produce either Java, IL or Melody for C/C++].

So I basically try not to make too many suggestions for gcc, except to say that Melody wouldn't be harder than Java or IL.

But for melody, I had f.e. specifically C++ in mind, when I described
the "let" statement which introduces a new scope. The "let" describes an
expression which evaluates with a certain name-binding. The name-binding
has an initializer and a cleanup. "let" gives Melody the ability to
describe scope/destructor semantics in object-code, which would make it
clearly superior to bytecode, where scopes and scope-cleanup cannot be
recognized anymore.

The advantage is the following: Now the compiler hasn't got to specify
anymore, how scope cleanup has to be /implemented/ during an exception. He only needs to say, what has to be done for cleanup.

This makes it possible to map C++ exceptions to the exception framework of a specific virtual machine, without the need to code too many specific implementation details into the compiler.

Btw. One of my objectives is, to investigate if C/C++ can be made an M$-IL language, without M$'s proprietary extensions, because Melody contains enough informations to integrate C++ into M$-IL. I.e. if the runtime integration can be done using only the means defined by the ISO Standards.

>>No. The idea is to make Melody strong enough to generate Java or IL if
>>required, thus requiring only one portable executable format for all
> Well, since (for strategic reasons) we need to be "downward
> compatible" to .NET, I think this is not going to work out for
> DotGNU.

Hmm..Doesn't it look like we'd have this:

* Every dotGNU language can compile to Melody.
* Every Melody can be compiled into IL.
* Every Melody can be compiled into JavaVM.
* We can support framworks that work unter JavaVM, IL and Melody.
* The Melody-Framwork is better, because it has a more sophisticated IL.
* Proprietary Implementors must support dotGNU if they want to benefit from Melody
* dotGNU runs best on free Platforms.

The only problem I see is, that Melody would be the Super-Assembler we don't want give proprietary implementors for free. Anyway, I don't stil quite understand the issues around gcc fully (i.e. isn't C already a super assembler?) so I'd need thinking about that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]