Re: Porting to darwinports

"Scott G. Miller" <[email protected]> Sat, 18 Dec 2004 17:53:35 -0600
Newsgroups gmane.comp.java.sisc.devel
Message-ID <[email protected]>
On Sat, Dec 18, 2004 at 03:53:36PM -0500, [email protected] wrote:
> > > Is there anything that Groovy, Jython, or JRuby can do in terms of
> > > bridging with Java libraries and the JVM and interoperating with Java
> > > semantics that SISC cannot?
> >
> > If any of them compile classes on the fly, its possible that they may be
> > able to extend classes from the dynamic language.  This is a feature
> > we'd like to add in the not too distance future.  One can implement
> > interfaces quite easily using the define-java-proxy functionality
> > however.
> >
> > 	Scott
> >
> 
> Interesting.  Jython and Groovy both compile Python and Groovy files down
> to Java byte code, generating a corresponding .class file for each source
> file.  JRuby does not do this currently.
> 
> >From what I've seen of SISC, it  does not compile down Java byte code
> either, but to an intermediate representation, which it then interprets. 
> Is the goal of SISC to start generating JVM byte code as well?  That would
> certainly provide a high degreee of interoperability between Java and
> Scheme.

We have a high degree of interoperability between Java and Scheme 
(compilation is unnecessary to achieve that).  But it is not possible to 
compile Scheme to JVM byte code and attain all three of:

1) Respectable performance
2) Full continuations 
3) Proper tail recursion.

SISC is within 30% of compiled Kawa in informal testing, and not only 
implements 2 and 3, but is faster than most C based compilers for 
continuations.  Both Kawa and JScheme sacrifice 2, and Kawa can attain 3 
only in a degraded performance mode.  

Scheme is a different language than Ruby and Groovy.  The latter two 
languages are remarkably similar to Java already, except in the areas of 
syntax and their being more dynamic.  Scheme is a functional language, 
and so has a number of unique features (first class functions, 
continuations, hygienic macros, etc) which don't map well or at all to 
the JVM.

	Scott
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBxML/r9IW4v3mHtQRAk0IAJ0WK5G0iMQW8rB5VySYw0LDvwSJ9QCfXHxu
qSxrao5hrx8MI9KTj211grE=
=1VRh
-----END PGP SIGNATURE-----