From: | Jeff M Younker <jeff@uh.edu> |
Newsgroups: | comp.lang.java,comp.compilers,comp.lang.sather |
Date: | 30 Jan 1996 18:26:11 -0500 |
Organization: | University of Houston High Performance Computing Center |
References: | 96-01-037 96-01-089 96-01-109 |
Keywords: | translator, OOP |
(I'm forwarding this to comp.lang.sather. I think they may have
something interesting to offer ).
David Hopwood wrote:
> Here is my estimation of how hard it would be to translate various languages
> to the JVM. YMMV.
> ...
> More difficult (problems are MI and genericity):
> Eiffel, Sather
> ...
My own take on Sather to JVm is that MI (Multiple Inheritance) is in
no way a problem. Both Sather and Java perform accomplish MI through
interface inheritance. The problem with inheritance is due to the
fact that Java does not make a complete distinction between interface
and implementation inheritance. Java allows the two to be merged when
doing single inheritance. This causes problems with the class
libraries. There are classes (such as InputStream) which should
interfaces, but are classes. It gets a little messy, and I'm not sure
how a Sather compiler would reconcile the Sather type system and the
structure of the Java Libraries.
Parameterized functions are slightly harder, but the Sather folks
(both ICSI and SatherK) have already solved this one. After all, no
assembly language that I know of has parameterized classes, and they
know how to compile to assembly. Hopefully even this little porting
problem will disappear with Java2. (I have heard rumors that it will
have parameterized classes. For the C++ folks: "templates" ).
The ugly part of the compiler would be Sather's iters. They are the
single coolest innovation in Sather. They are a way of generalizing
iteration and looping ( A good, short paper on them is at
http://www.icsi.berkeley.edu/~davids/pubs/toplas.ps.gz ). They are
simple to use, and very powerful (Now the sales pitch ends). For
implementation purposes, they can be looked at as specialized
coroutines, or (what else) closures (with a limited life span). This
puts a speedy implementation on equal footing with scheme. It seems
that everybody wants closures in the JVM (or at least coroutines).
- Jeff Younker - System Administrator, HPC - jeff@hpc.uh.edu -
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.