My last
post dealt with how I evolved a preference between two different
implementations of the Scheme programming language, each of them
written in Java: how and why I came to decide that I preferred SISC
over JScheme. I want to make some follow-up points about how
one might compare and contrast the two implementations.
My overall theme is that their design goals are different, and that
they should be judged accordingly. This may help to explain why,
though that last post was titled A Better Scheme, at the end of it I
backed away from saying that SISC is "better" than JScheme, preferring
simply to say that I prefer SISC.
The key difference in design goals was stated
by Tim Hickey, one of
the principal developers of JScheme, in an e-mail message to the
"SISC-users" mailing list, dated 2002-05-31. He said: "SISC
seems to be written with R5RS conformance and high performance in
mind, whereas Jscheme was designed to allow easy access to Java. It
can be thought of as a 'Scheme skin' over Java...." (The full
message can be
found here,
in the archives
at SourceForge.net.1)
Okay; JScheme was designed with "easy access to Java" in mind.
In other words, it is supposed to be easy to call Java methods from
JScheme. One important aspect of how this is achieved is called,
by the JScheme
developers, "The
Java Dot Notation."
Let's look at an example of this notation: of how one would call a
Java "instance method" from JScheme. I'll randomly choose the
"after" method of java.util.Date, which is declared thus:
public boolean after (Date when)
So if we have two Date objects, date1 and date2, one example of a Java
statement which calls this method would be
boolean later = date2.after(date1);
An approximate equivalent of this in JScheme would be:
(define later (.after date2 date1))
In JScheme, a symbol beginning with a period, such as ".after", is, in
general, interpreted as the name of a Java method; that method is
called on the Java object which is given as the first argument of this
Scheme "procedure".
To do the same thing in SISC requires more code:
(define later
(->boolean ((generic-java-method 'after) date2 date1)))
So yes, in a simple sense, access to Java is easier from JScheme than
from SISC. Pragmatically, this could certainly be seen as an
advantage that JScheme has over SISC, in some use cases, at
least. However, some in the Scheme community don't see it as an
advantage at all, but rather as proof that JScheme is not faithful to
the classsic simplicity of Scheme, and should be shunned.
Since I have already said that I prefer SISC, you might assume that I
would be one of these people. I was for a while, but not any
more. For me, the Javadot notation, per se, is not objectionable.
In a subsequent post, I will lay out the nature of the objection, and
why I no longer think it has merit.
1Note added 2008-04-09: The e-mail message, as it appears
in the archive, doesn't actually say that JScheme "can be thought of
as a 'Scheme skin' over Java", but that it "can be though of as
..." However, since I can't parse "can be though of", I have
taken the liberty of assuming that Mr. Hickey meant "can be thought
of", and editing the quotation accordingly.
Categorie(s) for this post:
Scheme.
6:21:07 PM 
|
