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