Re: Possible to write compiler to Java VM?

boutell.com@holly.aa.net (Thomas Boutell) writes:
> BASIC (don't laugh):


I'm not laughing at all. Makes plenty of sense to me.


> Pascal:
> Fortran:


You've got to watch out for by-reference parameters in these two
languages. That's not a killer for safety (Modula-3 is a safe
language, with by-reference parameter-passing mode, for example) but
the Java VM doesn't support it directly. You could fake it, of
course, but the additional level of indirection and allocation would
be burdensome.


> Lisp and Scheme: closures are a problem, unless perhaps the activation
> records can be kept on the heap rather than on the stack, as has been
> suggested in comp.lang.java (I believe).


My guess is that it would be ok to just make lots of the Lisp/Scheme
runtime data structures into java objects by default. With luck/work,
you might be able to optimize a decent number of calls to avoid the
heap. I guess the reason I think this is that since the language
already has a heap, I see no reason to turn the stack into another
heap. It has a heap, use that for things that need to be allocated on
the heap. It has a stack, use that for things that can be allocated
on the stack.


> C: probably the worst candidate for a good port.
> C++: see above, but more so. [but sort of misses templates]


You bet. By-the-way, be careful not to confuse Java and the JVM. For
all its complexity, the C++ template system just bangs out code as if
from a stencil, and the front-end language (Java or whatever) could
bang out code as if from a stencil, and generate the byte codes for
each of the instances of the template. IT WOULD BE NICE if there were
some sort of VM support for shared-byte-code templates, but when I
thought about this, it got messy. If you (or anyone else) care, the
approach that I find most interesting is what is described in some of
the work on Theta by Liskov et al at MIT. See
http://clef.lcs.mit.edu/, or their article (Day, Gruber, Liskov,
Myers) in OOPLSA '95.


speaking for myself,


David Chase
--

Return to the comp.compilers page.
Search the comp.compilers archives again.