Tom Edelson's Songline
Writing about computers, life, and society from the perspective of a "poly Quaker Taoist" living in the Triangle region of North Carolina.

Subscribe to "Tom Edelson's Songline" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

Monday, February 11, 2008

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, 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 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 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    comment []

Click here to visit the Radio UserLand website. © Copyright 2008 Tom Edelson.
Last update: 3/19/08; 9:11:51 PM.
February 2008
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29  
Aug   Mar