[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Internet C++
Re: [DotGNU]Internet C++
Wed, 08 Aug 2001 07:58:49 +0200
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801
Jose Gonzalez wrote:
> Hello everybody.
> I'm new in this forum so i'm sorry if what I say has already been
> mencioned before or it's not right at this moment
> (anyway, I haven't seen anything about this in the FAQs)
> If my ideas are OK, Melody is a intermediate step to accommodate several
> high level languages, with
> different features (pointers, multiple inheritance,...) over a bytecode
> choosen from several posibilities (JVM, M$ CLR ,..)
> My question is: it's not posible to solve this problem using the an
> appropiate bytecode? I mean something like Internet C++
Regarding Internet C++. I quote Rhys Weatherley's comment from the
dotGNU-arch list here:
"This project cropped up on Slashdot last October.
It isn't really "open source", so much as "available source".
The core VM engine was over 200,000 lines of
autogenerated C code, generated from some template
that wasn't supplied.
The Slashdot article is
My message pulling it apart is there: search for
"rhysweatherley". In a nutshell: wrong design,
and totally insecure. If this was used for DotGNU,
it would need to be completely rewritten. It looks
like the code hasn't been updated since October,
so the maintainer has dropped off the map."
A quick and clean kill.
Melody is (would be), to have a high-level representation of code, which
removes the need for the compiler implementor to put implementation
details into the generated code. For example, a C++ compiler must
somehow stem destructor cleanup into the byte-code and he would, say,
generate tables with cleanup handlers, which an exeception handler would
need to interpret. In other words: we had to define /the one ABI/ for
that, which every language must to follow. But the JavaVM and the M$-ABI
already have their own ways to deal with exceptions - And this would
mean, that our compiler would need to know, for which target they
produce, in order to know which ABI they had to serve.
Melody then, would offer the source language a way to say: "I introduce
a variable here, and it is valid during this expression and after that
expression is done (not matter if it succeeded), I want that this
cleanup expression is done". And now it's a matter of the Melody=>M$-IL
or Melody=>JavaVM or Melody=>GCC translator to figure out how that
constraints can be mapped on the ABI of the target architecture.
In short: Melody would be like a firewall between the source language
and the target platform. And hopefully efficient if interpreted as
target machine itself.
I am not sure if that's official. But I doubt that everyone one this
list endorses HTML posts. multipart/html triples the traffic without
adding one bit of information. Also you can expect, that not everyone
has a mail client that can display HTML, and if he could, I would bet
that the feature has been turned off.