Re: Possible to write compiler to Java VM? (I volunteer to summarize)

"Peter Seibel" wrote:
>So I'm asking you all: how easy/hard/impossible would it be to write a
>compiler for your favorite language(s) that compiles to Java VM
>byte-codes. ...


All right, let's play with this a little. I've been over the Java VM
spec. My comments reflect the languages I know most about, of course.


BASIC (don't laugh): BASIC traditionally lacks pointers (especially in
the Visual BASIC era; let's leave PEEK and POKE out of this). Also,
BASIC traditionally has a large standard library (expressed as a
muddled collection of special-purpose statements). Finally, BASIC
traditionally has a strong string type. All of these characteristics
are very much compatible with the Java VM design and the standard Java
classes. Simple BASIC dialects would just compile to a single class
file; dialects supporting some degree of OOP would map easily to a
subset of the Java class system. Expect to see multiple BASIC->Java VM
compilers quite soon indeed.


Pascal: no problem. Dialects of Pascal that are actually popular:
these can be a problem to the extent that they may allow the
equivalent of C's pretty-much-unlimited typecasting. I suspect that
Delphi, in particular, is much closer to Java in typical use than
other Pascal dialects and will port quickly if Borland does its
homework.


Fortran: if the arithmetic specs turn out to be compatible, this
shouldn't be too difficult. It helps that the Java VM spec is quite
explicit about math issues. Large bodies of existing high-quality
mathematics code are the main reason Fortran is still in use.


Eiffel and Sather: these are great candidates for the Java VM if the
multiple inheritance features can be implemented successfully using
the Java class file system.


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).


C: probably the worst candidate for a good port. A faithful
implementation of C would be impossible without wrapping it up in *yet
another* virtual machine, and C is traditionally expected to be a
high-performance, low-level language. The difficulty in porting C to
the Java VM lies in the fact that C is breathtakingly
non-type-safe. If you decide to break a lot of code and clean up those
problems, you wind up with something that (a) is not C and (b) is
suspiciously similar to the Java language itself. "There are those
who say that this has already happened."


C++: see above, but more so. C++ does have several features which are
missing from Java, most notably multiple inheritance and generic types
(templates). I don't much care for the C++ template syntax, but the
loss of the functionality itself is rather painful. Java would be a
lot more elegant if I didn't have to cast stuff every time I use a
Vector object. C++ doesn't have a stable and well-established standard
class library worth using, either, despite its age (perhaps if there
had been a standard string class oh, say, four years ago...). May as
well use Java itself.


Perl: I don't see any technical barriers to this. Perl does have
closures but I get the impression they are closer to Java's exceptions
in implementation complexity.


Python: see Perl and Scheme.


Other thoughts?


-T
--

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