Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!sfk
From: sfk@otter.hpl.hp.com (Steve Knight)
Newsgroups: comp.lang.lisp
Subject: Re: In defense of call/cc (and a plug for T)
Message-ID: <1350036@otter.hpl.hp.com>
Date: 16 Feb 91 10:21:04 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 39

> If I don't have call/cc then I have
> no recourse other than to go begging to LISP manufacturers or write my own
> compiler.

As I mentioned in a previous posting, call/cc and various other coroutine
models (Poplog processes are just one example) are equivalent and can be used to
implement each other.  The difference lies in the implementation technology.
(Of course, one may still prefer call/cc over other multi-threading models.)

So, provided language designers have aniticipated the need for multi-threading
in some shape or form, there is a good chance the begging bowl can stay at
home.  It's a bit of a shame CL provides no such facilities -- but it gives
those of us who find CL the least acceptable Lisp around a really big
stick to beat up our managers with :-)

Steve

PS. My own personal gripes with CL are [1] the type system is far too loose
[2] user-defined types aren't guaranteed to be distinct from previous
types [3] equality doesn't work the way it does in other lisps & is 
a nasty source of problems (e.g. portability) [4] there's no multi-threading
[5] I don't like keyword parameters/optional parameter etc and dislike
paying a cost for a feature I don't use [6] empty list and false still
aren't distinct [7] the lack of temporary (transparent) hash-tables 
(c.f. Poplog CL, T) [8] the lack of destroy actions (c.f. Poplog CL)
[9] the poor choice of initial syntax features (defun, do) [10] the
dual name spaces for functions and values (bletch!) (use type hints
to avoid the usual complaints of efficiency (see Pop11)) [11] type assertions
are unchecked & are effectively promises rather than hints (I'd like
both, thanks) [12] the lack of a updaters (see Pop11) for an update
model that can support abstraction (SETF is a compile-time thing).

On the other hand, CL gets my thumbs up for {1} putting lexical binding
on the map once and for all {2} its excellent number model {3} the
size of its library (implementations all too often are sloppy in doing
this, see Poplog CL for an implementation that avoids dragging in every bit
of code (even the different cases of FORMAT are separately loaded)) which
I suppose could be better thought out {4} for (mostly) successfully uniting 
the Lisp community behind a single Lisp.