jmiller@CHAOS.CS.BRANDEIS.EDU ("Jim Miller") (02/13/90)
Archive-name: survey-scheme/11-Feb-90
Original-posting-by: jmiller@CHAOS.CS.BRANDEIS.EDU ("Jim Miller")
Original-subject: Does scheme run on the DECStation 3100?
Archive-site: zurich.ai.mit.edu [18.26.0.176]
Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)
There are four versions of Scheme that work on the PMax (DECStation
3100) of which I am aware: Yale's T (not "true" Scheme, but a variant
with a mode very much like Scheme), DEC's Scheme->C, Brandeis's
Gambit, and MIT's CScheme. Of these, the first three are
compiler-based and the last is currently an interpreter, but I am
sitting down today (a true coincidence!) to do the compiler port. It
is possible that Dybvig's Chez Scheme system has been ported to the
MIPS as well, but I am not certain (contact
dybvig@iuvax.cs.indiana.edu).
Here's my current, personal, biased assessment of the four systems:
(a) Yale's T: similar, but not identical to Scheme. A very well
designed Lisp system with a high performance compiler. Unfortunately,
the compiled semantics do not match the interpreted semantics, and
there are severe (but rare) garbage collector bugs. The development
environment is good for interpreted code but moderate to poor for
compiled code. I believe T is available by anonymous ftp from
zurich.ai.mit.edu.
(b) DEC's Scheme->C: a true compiler with good performance and an
associated interpreter. The development environment is poor (it is
really intended for a final delivery environment, not program
development), and the implementation is not "fully tail-recursive" as
required of a true Scheme system. On the other hand, it generates C
code that can be compiled and linked with other C programs allowing
Scheme to call C and vice versa. Contact Joel Bartlett
(Bartlett@decwrl.dec.com) for a (very liberal, but not public) license
agreement.
(c) Brandeis's Gambit: a true Scheme compiler with very good
performance. It currently generates portable C code for use on the
PMax. It was designed to be easily ported and two undergraduates are
currently doing the port to the PMax. The output code is very
efficient on the 68000 machines and will probably be equally good on
the MIPS. Gambit, like Scheme->C, has a vestigial development
environment. Unlike Scheme->C, it does not support C call in/out.
Available by anonymous ftp from zurich.ai.mit.edu, but contact
Feeley@cs.brandeis.edu for details and information about the MIPS
port.
(d) MIT's CScheme: a true Scheme with an elaborate development
environment. Debugging code, compiled or interpreted, is by far the
easiest in this system; but the performance of compiled code is
roughly half that of the other systems. Like T, but unlike Scheme->C
or Gambit, the runtime support supplies a large variety of procedures
beyond those specified in the Scheme standard(s). Available by
anonymous ftp from zurich.ai.mit.edu, but contact me or
cph@zurich.ai.mit.edu for information about the compiler port. I
should know in about two weeks how hard the port will be.
Finally, on the differences between Scheme and (Common)Lisp:
(a) Scheme and CommonLisp are both Lisp dialects. That is, they share
the underlying singly-linked list data structure, automatic storage
reclamation, and a nearly complete lack of syntax.
(b) Scheme is smaller in just about every measure than CommonLisp. It
has fewer syntactic forms, fewer built-in procedures, and generally
smaller implementations. A minimal CommonLisp implementation already
has a useful program development environment while several of the
Scheme systems described above are designed as delivery vehicles with
minimal development support.
(c) Scheme has a more uniform treatment of procedures and variables
than CommonLisp. Scheme has only lexical variable reference
while CommonLisp has "special" variables that are dynamically bound.
Scheme has a single namespace, while CommonLisp has many (variables in
procedure position, other variable references, PROG labels, etc.)
(d) CommonLisp has a standardized package system based on prefixing
symbol names, while Scheme has no universally accepted package system.
CommonLisp has a standard syntax extension mechanism (macros), while
Scheme macros are not yet standardized (although consensus is expected
soon).
(e) While Scheme is smaller than CommonLisp, it does contain one
operation not supported by CommonLisp: call-with-current-continuation
(sometimes referred to as call/cc). This procedure, about which there
is a good deal written in the literature, provides a program with
access to its own current control state. Using call/cc almost all
known sequential control constructs can be implemented.
(f) There are multiple public-domain versions of Scheme, but to my
knowledge only one complete public-domain version of CommonLisp (Kyoto
CommonLisp or KCL). The price of a non-public Scheme system is far
lower than the corresponding price for CommonLisp.
(g) Converting code from CommonLisp to Scheme is generally very
difficult because of the size differences between the languages.
Converting from Scheme to CommonLisp is generally easy as long as one
avoids the more exotic uses of call-with-current-continuation and
macros.
--Jim