[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


   Date: Thu, 4 Feb 88 21:51:40 EST
   From: Mitchell Wand <wand%corwin.ccs.northeastern.edu@relay.cs.net>
   [There is considerable irony in this analysis.  Sussman has said on several
   occasions that he was never interested in Scheme as a programming language; he
   was just interested in writing some code.  I'm not sure about Guy's feelings
   on this. ...]

I'm interested in writing code too.  To the extent that it is easy and
convenient for me to use a machine to try out my code, so much the better.

One of the best things about Scheme is that the important parts can be
written down in one page--or carried around in my head.  Not having
standard Scheme implementations has not bothered me too much, because
I can turn ANY Lisp into a Scheme with about half an hour of work.
(Usually I am trying out a language design idea by making a toy variant
of Scheme, so I am writing my own evaluator anyway.)

Scheme is small and clean and has a nice semantics.

The kernel of Lisp 1.5 had many of the same properties.  Scheme differs
primarily in having better scoping rules, and in general a more carefully
thought out semantics, thanks to many people who have carefully discussed
the issues over the last 1.3 decades.

However, it is also useful to have standard libraries.  I am happy to see
lots of useful numerical utilities in a Scheme, for example.  It's great to
have ATANH and GCD.  I wish factorial and choose (actually the generalized
gamma and beta functions) and Fibonacci were built in also.

I have recently had some experience in trying to write large systems
in Scheme.  Where it differs from Common Lisp in fundamental structures
(such as control and binding), it is all to the good.  What I miss from
Common Lisp are the little utility routines like STRING-TRIM that I must

Nevertheless, if Scheme is to be standardized I recommend that everyone
on the committee try to refrain from advocating their favorite ten
extra features.  Scheme cannot withstand having n people add 10n
new features; the result would be a patchwork, not unlike another Lisp
dialect we all know.  Perhaps the committee should agree to adopt a
Rule of One (cf. Lloyd Biggle's "The Still, Small Voice of Trumpets"):
each person gets to choose *one* new feature to propose.  That makes
you sit and think carefully.

I have thought about it very carefully, and I choose for my One Feature
to propose that a function like Common Lisp's REDUCE be added (but with
not so many of the keyword-triggered options).  I use that a lot.

Perhaps this is too draconian a rule for a committee, but I still suggest
it as a good personal discipline.