As well as it can, considering I'm the only one working on it,
and only for a few months was it more than very part-time.
> Really? I would have thought that the JVM would strip out information
> needed for efficient compilation. Do all of the well documented
> [1]problems of Lisp family languages on JVM disappear when it is run in
> a JIT?
I think most of the problems are inherent in the architecture,
at the level of objects and calling conventions, rather than the
level of specific instructions. I.e. if you want to implement
multi-dispatch, you have to do it using a library routine.
Of course, that is not an issue for standard Scheme.
Closures and numbers have been mentioned as problems.
I don't really see that. Closure are straight-forward to implement,
and have in fact been added to the Java source for JDK 1.1.
(No VM changes are needed.) First-class functions can be
implemented using procedure/closure objects (as currently in Kawa),
or using the JDK 1.1 reflection features (java.lang.reflect.Method).
I may switch to the latter for Kawa.
Numbers are easy to implement using Objects. A concern is that
always boxing interers will strain the gc, but the solution
is preallocate small integers (say up to 1000). Implementing
plus by method dispatch (or class testing) may be a bit slower
that shift+mask, but probably not too much so, especially for
native-compiled code. In any case, the only way to get real fast
fixnums is to use native unboxed ints and use optional type
declarations. I happen to think that optional type declarations
would improve Scheme programming, and intend to add them to Kawa.
But I don't think "stripping out information" is a fundamental
problem. A compiler can "peephole-optimize" idioms that it recognizes
from (say) Kawa. The Java .class file format also provides hooks for
optional "attributes" where a Scheme compiler can store useful
Scheme-specific data (such as debugging information).
> > However, with a reasonable module
> > system, or suitable annotations/switches, if the compiler can
> > statically bind 'cons to the standard cons function, it can
> > generate much better code.
>
> Which compiler is this, the JIT, or Scheme->ByteCode?
I meant Scheme->bytecode. I would like
(cons x y)
to translate into a call to a known static method:
List.cons(x, y)
which could be inlined to:
new Pair(x, y)
The first optimization requires knowing that 'cons has not been re-defined.
The second is standard inlining. The result will be about as the same
as you would get with any Scheme implementation.
> This is interesting, as a high level front end to a front end, which
> makes the JVM an even better target for language research. But won't it
> result in slower executables than if Scheme or Java were compiled
> directly? Isn't there some information loss (especially for Scheme) in
> going to byte codes?
I guess. Off-hand, I can't think of anything important. And as I said
above - you can always add Scheme-specific attributes to the bytecodes.
These are ignres by VM s are compilers that do not recognize them.
--Per Bothner
Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner