Re: RE: XML] Re: SIDE NOTE: CIL Schema

On 11 Jan 2005, at 17:23, Miller, Brian wrote:

> I think a bytecode->MLML->JavaScript translator would
> be better than one that consumes Java source.

Java bytecode instructions look quite different than JavaScript 
statements, whereas Java and JavaScript are very close in that respect. 
It would make any bytecode -> JavaScript translation difficult, 
compared to Java -> Javascript.

Representing (byte- or source-) code in MLML doesn't mean translating 
it to a completely neutral format - Java in MLML format would still be 
distinctly Java. This might seem a bit disappointing, but then _there 
are no silver bullets_!

But yes, bytecode  -> MLML is very poss - for example Antlr has a 
bytecode grammar already available.
As a thought, Java bytecode -> MLML -> CLI bytecode, and the other way 
around, should be straightforward.

Still one must keep in mind that translating the code doesn't mean that 
it will compile, link or run - unless you translate the entire set of 
runtime classes/types that the code uses. That would effectively mean 
building a Java emulator in JavaScript, which I believe is roughly what 
Alex has already done.

I'm otherwise interested in implementing o:XML -> MLML -> bytecode, 
using something like BCEL [1] for programmatic code generation. It 
takes a lot of the sweat out of bytecode generation. That and similar 
transformations are definitely part of the rationale behind MLML - as a 
means to achieve backend, or execution platform, independence. The 
motto could be: compilation is a form of premature optimisation - which 
we all know is the root of all evil!

> Emitting JavaScript has appeal.  JavaScript is the desktop's only
> universally installed virtual machine.

I totally agree, generating JavaScript has huge appeal. I'm aiming to 
eventually create an o:XML -> MLML -> JavaScript translation for this 
very reason! With o:XML I can make the minimal core language very 
small, and define a runtime library using that minimal core. It would 
make it much easier to port the runtime to different backends, compared 
to porting for example Java, which has a huge runtime environment. The 
same thing could be done with eg J2ME, but creating the runtime would 
require _lots_ of work.

If I understand Alex G correctly he has accepted this, and is instead 
wishing to write code for the JavaScript runtime environment using the 
Java source code format.

/m

[1] BCEL http://jakarta.apache.org/bcel/