I have now done enough programming in Scheme to be able to say
confidently what I've long suspected: that it's my favorite
programming language. Of the ones I know well enough to judge,
that is; I will never know for sure whether there's something else out
there that I would like better ... because no one can learn enough
about all existing programming languages to make an informed judgment
about such a question.
All of my serious Scheme programming, to date, has involved the
"scripting" of existing Java code. This, at the very least,
biases me toward using a Java-based Scheme implementation, meaning one
that runs on the Java Virtual Machine: it would certainly
be possible to script Java code from outside the JVM (after
all, one can script Java code from Perl), but given that at least one
acceptable Java-based implementation of Scheme exists, why not use
one?
As those familiar with the Scheme world know, the language
suffers from an embarrassment of riches where implementations are
concerned. One list,
at community.schemewiki.org,
has about seventy of them ... and I know for a fact that that's not a
complete list.
And Robert Tolksdorf's
list of Programming
Languages for the Java Virtual Machine has no less than fourteen
entries (all of them under the heading "Lisp and co") that claim to be
full or partial Scheme implementations, for the JVM alone.
(Nine of the fourteen appear in the list at community.schemewiki.org
as well. Also see "Footnote 1" below.)
At any rate, of nine implementations that appear in both lists, I now
have experience with two of them. I began
with JScheme
(see "Footnote 2"), and have now moved on
to SISC (Second Interpreter of
Scheme Code). You would be correct in inferring, from the way I
phrased that, that I have decided that I prefer SISC.
Why do I prefer it? In part, because it's a complete
implementation of "R5RS", the most recent generally-accepted standard
for the language, and JScheme is not. (Yes, there's a story
behind that qualification, "generally-accepted", but it will wait for
another time.) I will note at once that JScheme doesn't claim to
be; it's never claimed to be more than a "nearly complete"
implementation of R4RS, the previous version of the standard.
However, while the JScheme page linked above says "JScheme implements
all of R4RS Scheme except that continuations can only be used as
escape procedures and strings are not mutable", that list of
exceptions is not complete. The JScheme implementors have
written elsewhere (I can't seem to find the reference right now) that
"the numeric tower is not right", or words to that effect. I'd
have to call that an understatement ... or at least, the way I
initially interpreted it was an understatement. I thought it
probably meant something like: JScheme does not support complex
numbers, only real ones.
As it turns out, the best succinct statement of how JScheme handles
numeric data types is: the JScheme numeric types are the Java numeric
types. For example, among integer values, it distinguishes
between an int (31 bits of precision) and a long (63 bits). In
some cases, if you push the limits of these types, you get
wrong answers in JScheme [version 7.2].
For example, suppose that you start with the number
1,073,741,824
(two to the thirtieth power). If you ask JScheme to multiply
this number by two, it tells you that the answer is negative. If
you ask it to multiply the same number by four instead, it tells you
that the answer is zero.
Actually, many software programs, and programming languages, are prone
to such errors, where large integers are concerned. In Java,
some of the same things will happen, by default. The programmer
can prevent them, but only by making the program more
complicated. But the Scheme standard says that, in cases like
these, a Scheme implementation should give the mathematically correct
answer, without special effort on the part of the person writing the
Scheme code.
And SISC does.
It's not clear that this limitation in JScheme would have made a
practical difference, in the project I was working on when I
discovered it: it's not clear that my program ever would have
encountered numbers that large. But I didn't want to have to
worry about it. And, practical consequences or no, I found it,
let's say, aesthetically unpleasant, given that this is supposed to be
Scheme, and that [relative] mathematical correctness is one of the
defining characteristics of Scheme, in my mind at least.
This funny business with numbers was just one of several reasons why I
came to decide, in the middle of a project, to stop trying to write it
in JScheme: to convert what I'd already written to use SISC instead,
and then resume adding functionality to the program. From a
broader point of view, one could say that I was motivated by the fact
that this was my first significant Scheme programming project, which
means it was my first opportunity really to learn (as opposed to
learning about) the language. I decided that it was a
waste of time to learn the habit of working around limitations in
JScheme, if I didn't intend to keep using JScheme for the rest of my
Scheming career.
And yet ... despite the title of this post, I don't really want to
make an absolute statement that SISC is "better" than JScheme.
It depends on what you want. If you want a "mostly Scheme-like"
scripting language for Java, JScheme could be a perfectly reasonable
choice. If you really want to program in Scheme, you may prefer
SISC.
Footnote 1: the list of Scheme implementations at community.schemewiki.org
also has at least one entry,
for llava,
which is clearly Java-based, yet doesn't appear in
the above-mentioned Java-specific list.
Footnote 2:
the Tolksdorf
list of Java-based implementations has (as of today) two
confusingly similar entries, the first headed "JScheme" and the second
headed "Jscheme". It is the second of these which refers to the
implementation I've used ... though the correct capitalization of
that implementations's name is, in fact, "JScheme". The first
"JScheme" entry is a broken link (again, as of today), but clearly
refers to a different implementation with a similar name.
Categorie(s) for this post:
Scheme.
3:54:19 PM 
|
|
