Subject: Re: What kind of Lisp should I learn if I want to start programing with Lisp?
From: rpw3@rpw3.org (Rob Warnock)
Date: Fri, 06 Feb 2009 22:22:54 -0600
Newsgroups: comp.lang.lisp
Message-ID: <EK2dnWi2-MkDkRDUnZ2dnUVZ_hOdnZ2d@speakeasy.net>
joswig@corporate-world.lisp.de <joswig@corporate-world.lisp.de> wrote:
+---------------
| p...@informatimago.com (Pascal J. Bourguignon) wrote:
| > For example, we could take the intersection of Scheme features and CL
| > features, and define a subset of CL that would be as simple as Scheme
| > to implement (simplier since you wouldn't have continuations).
| 
| Right. But there is no (see below) useful such subset defined.
+---------------

While you are correct that there is no *standard* subset defined,
the CLHS 1.7 definition of "subset" is so broad that many, many
useful (to someone or other) subsets can easily be defined.

+---------------
| Just to take things out of Common Lisp takes time.
+---------------

IMHO, it's a lot faster to come at it from the other direction
and only put *in* what you really want/need!  ;-}

As I have mentioned here before, I've been dabbling around with a
tiny subset of CL that I call QDL ("Quick & Dirty Lisp"), currently
just a pure sexp interpreter written in C. Including a precise GC,
the latest version is ~4 KLOC [would be somewhat less, if you took
out some huge chunks of debugging code], with only 40 symbols in
the oblist at startup [omitting debugging extensions]:

    QUOTE LAMBDA PROGN FUNCALL APPLY EVAL
    IF SETQ DEFUN LET LET*
    PRINT PRINC TERPRI
    SYMBOL-VALUE SYMBOL-FUNCTION
    LENGTH
    CAR CDR CONS LIST ASSOC REVERSE NREVERSE
    VECTOR
    1+ 1- + - * / = /= < > <= >=
    GC ROOM OBLIST

[O.k., so OBLIST isn't standard; (defun oblist () (apropos-list "")).]

Still, QDL's big enough to run (ACKERMANN 3 10) [takes ~6 minutes
on my laptop]; it has proper lexical closures [including DEFUNs
that can share non-null lexical environments]; but only fixnum
arithmetic so far. As Pascal_B suggests, not having to guarantee
"safe-for-space tail-call chains" makes it a *lot* easier to throw
soemthing like this together in C.

+---------------
| It would make sense to have such a thing, IMHO.
+---------------

If only as a tool for bootstrapping a full CL [which is one of
the intended future uses of QDL, but that's another story].

+---------------
| Even as a kernel language as part of a standard.
+---------------

Well, the ANSI committee quite deliberately chose to *not* bless any
particular subset(s). From CLHS "Issue SUBSETTING-POSITION:NONE":

    We have no well-defined proposals for subset definitions, and didn't
    have the time or energy to pursue their definition, or confidence
    that we could reach convergence on a reasonable definition.

After investigating this area a bit myself, I think that they were
quite right to take that position. CL has *so* many *nearly*-orthogonal
dimensions that while it may appear easy on the surface to "subset"
things, it's very difficult in practice to construct a sane transitive
closure of features that doesn't drag in the whole language!!  ;-}

[The one exception is CLOS, as several implementations have shown.
It's possible to define a reasonably-full CL subset less CLOS, then
bootstrap CLOS on top of that later.]

Anyway, that's one of the things I'm trying to answer, for myself at
least, with QDL. Here's one (of several!) ways to phrase the question:
"By the the time you've grown a CL subset from 'nothing' to the point
that you might actually want to use it for real work (e.g., ship it in
a product, or at least use it locally in scripts that you run every day),
will it necessarily be so large that you might as well have simply picked
some other already-existing full CL instead?"  I consider this question
to be currently unanswered, but indications so far are that the answer
is likely to be "just use an existing full CL".

Note: This is *different* from the question of whether there is a viable
business model for creating an new full CL. I don't think so, but what
do I know about the Lisp business? This is *also* different from the
question of whether some good could come from yet-another-fork of one
of the existing full CLs. I'm more optimistic about that one, since
there have been some successes there in the past.

Yet *another* question is whether a very small CL subset can be a
useful teaching or tutorial or learning vehicle, as an alternative
to Scheme [which already has a plethora of small implementations!].
The answer there, I think, is already a resounding "Yes!". If what you
want is a CL subset about the size of R4RS Scheme, that can easily be
implemented from scratch, in C, in as little as a few days' time for
an experienced programmer interested in self-tutorial, or could be
stretched to a full term paper project in a Computer Science course.

Finally, there's the question of whether a CL subset can be useful
when researching possible modifications/alternatives to/in an existing
full CL. I *think* so, but I'm still working on that one...  ;-}

+---------------
| Well, almost. There are some languages that can be seen as subsets.
| It is just that there either unused or single purpose:
| * CL0  ( http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/
|          lisp/impl/clicc/doc/cl0.pgz )
+---------------

Thanks for the reference. Do you have any idea how CL0 compares
with, say, ThinLisp <http://www.thinlisp.org/>?

+---------------
| * SubL ( http://www.cyc.com/cycdoc/ref/subl-reference.html )
+---------------

Thanks, but insufficiently Lispy for me. They lost me here:  ;-}

    SubL does not support these Common Lisp datatypes:

      Multi-dimensional arrays
      Packages
      Pathnames
      Random-states
      Lambda-Expressions or Closures

Also, the weird separation of many common features into "procedural"
(imperative, with no value) and "functional" versions -- e.g., IF is
split into PIF & FIF -- is just "wrong" for a Lisp.

+---------------
| a slightly different language:
| * Stella ( http://www.isi.edu/isd/LOOM/Stella/)
+---------------

Again, insufficiently Lispy, for similar reasons:

    ...most STELLA conditionals are statements and therefore
    do not return a value.

Ouch!

+---------------
| Probably there are others.
+---------------

Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>.  ;-}
88 initial defined symbols, float-only arithmetic, 500 LOC of *very* dense C!
Then loading "init500.lisp" adds another 761 symbols, fleshing out the CL
compatibility a *lot*.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607