Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!mitech.COM!gjc
From: gjc@mitech.COM
Newsgroups: comp.lang.scheme
Subject: what is lisp, instead?
Message-ID: <9008132139.AA11205@mailhost.samsung.com>
Date: 13 Aug 90 16:30:00 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: gjc@mitech.com
Organization: The Internet
Lines: 70

Many interesting replies to this "what makes scheme" thing.

J Reese's detailed reply being a good guide for me (or anyone) who
would want to make SIOD into a full R^4 language at some future date.

The intro to the R^4 report makes an (unsubstantiated) argument about
keeping a language as small as possible, or at least, trying not to
add too many things to it. One cold hard way to substantiate this 
would be to look at what languages that have *made* it, and which
have *failed* (and of course ask *why*). Be that as it may, R^4 defines
a language that is sufficient for running interesting programs with interesting
features which _cover_ just about all other languages without being
as big as all other languages.

This *coverage* aspect has been one goal of lisp implementors.

But what makes lisp? From the point of view of an old Maclisp hack
like myself, three things:
* EXTENSIBILITY
* HOOKS
* STABILITY

The whole point of SIOD is to have a Lisp which *lives* *well*
together with code written in C. It is to recognize that C, and
code written in C is in the MASTER POSITION in our current little
universe. _COVERAGE_ comes from what can be done in C.

What is one requirement for living well with C? That if you
have a lisp-level call to a procedure like (equal (f x) (g y)) that
you must be able to call it at C-level as equal(f(x),g(y));

XSCHEME, ELK, XLISP, they are all small (although many times bigger
than SIOD), but all of them have rather awkward call sequences
between lisp and C code compared with SIOD.
(But since XSCHEME/ELK/XLISP have more stuff at lisp-level, they
may be better for people who are going to do more programming
at the lisp level).

SIOD is aimed at those C programmers who might want to do a little
lisp. It is aimed at people who might otherwise be tempted
to use the classic Unix tools of Lex/Yacc to build yet another
one of those countless little abortions we are faced with from day to day.
Example1: SENDMAIL.CF files. (A large abortion, not a little one).
Example2: MIT X-Window's TRANSLATIONS (maybe not lex/yacc, just home-brew).

A parting shot here. SIOD does run code from SICP, the book
(not the harder to find Teachers Guide, or the on-line problem sets,
which indeed would take a lot of modification work). Even lack of
BIGNUM's is not such a big deal. The second home-work assignment
in the lisp course I gave at Boston University was to implement
a bignum package (using binary representation, quite trivial but a
bit on the slow side). Most engineering students aren't much
interested in number-theoretic examples anyway. (They won't get
hit with Z-transforms, coding theory, probability and generating
functions until much later in life at most schools).

By the way, the cutest bignum package I've seen lately is
in a symbolic algebra package running in GNU EMACS LISP
(dynamic scoping, fixnums only (not even floats!)).


-gjc

p.s. Don't misunderstand me with respect to R^4. It does not force
a language implementation to be large. I have just been too busy
in the last year or so to do anything about having a set of
full R^4 built-in's for SIOD. The fully general CALL/CC stuff
does have an adverse impact on *living* *well* with C or just
about any other language [except ADA perhaps?], but that should
be subject to compromise.