|Re: Possible to write compiler to Java VM? (I volunteer to summarize) firstname.lastname@example.org (1996-01-23)|
|Re: Possible to write compiler to Java VM? Dirk.Craeynest@cs.kuleuven.ac.be (1996-01-25)|
|Re: Possible to write compiler to Java VM? email@example.com (1996-01-25)|
|Re: Possible to write compiler to Java VM? firstname.lastname@example.org (Bob Wilson) (1996-01-25)|
|Re: Possible to write compiler to Java VM? email@example.com (William Clodius) (1996-01-27)|
|Re: Possible to write compiler to Java VM? firstname.lastname@example.org (Thomas Dunbar) (1996-01-27)|
|Re: Possible to write compiler to Java VM? email@example.com (1996-01-27)|
|Re: Possible to write compiler to Java VM? firstname.lastname@example.org (Samuel Tardieu) (1996-01-28)|
|Re: Possible to write compiler to Java VM? email@example.com (1996-01-29)|
|[24 later articles]|
|From:||firstname.lastname@example.org (David Chase)|
|Date:||25 Jan 1996 15:03:04 -0500|
email@example.com (Thomas Boutell) writes:
> BASIC (don't laugh):
I'm not laughing at all. Makes plenty of sense to me.
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
> 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,
Return to the
Search the comp.compilers archives again.