Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: In defense of call/cc (and a plug for T)
Message-ID: <4154@skye.ed.ac.uk>
Date: 18 Feb 91 14:36:27 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov> <1350036@otter.hpl.hp.com>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 139

In article <1350036@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
> 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 :-)

> PS. My own personal gripes with CL are 

CL is not without it's problems, but it's here now and it's usable.
Scheme is better for some things, not for others (though it is being
improved).  The idea that CL is especially bad as Lisps go seems to
me to be wrong.  It's better in many ways than quite a few other
Lisps.  Really.

In any case, most of your gripes are about things that don't
particularly both me, and here's why.

   >[1] the type system is far too loose

In what way?  So general a complaint tells me almost nothing.

BTW, my experience has been that when two people make the same
complaint about CL they often mean different things by it 
(especially if they strongly dislike CL).

   >[2] user-defined types aren't guaranteed to be distinct from
   >previous types

They aren't?  (Of course, it's trivially true that they aren't,
because they will be a subtype of T.)

Some implementations have made defstructs subtypes of vector.
Maybe that was a bad thing.  In any case, X3J13 decided to 
make array and defstruct types disjoint.

   >[3] equality doesn't work the way it does in other lisps & is 
   >a nasty source of problems (e.g. portability) 

What?

Perhaps you mean not the same as in _some_ other Lisps.

In any case, I don't know what problems of equality you have in
mind.  If you mean EQ on numbers, that's a problem in every Lisp
I know anything about.  The big difference in CL is the addition 
of EQL.

   >[4] there's no multi-threading

True.

   >[5] I don't like keyword parameters/optional parameter etc and dislike
   >paying a cost for a feature I don't use 

What cost?  Especially if you don't use them.

There's some cost in implementation size, but for most calls to
built-in functions that use keywords the keywords can be compiled
away.

BTW, I partially disagree with ram+@cs.cmu.edu (Rob MacLachlan), who
wrote:

   Well, I agree that optionals are mostly a loss, but you shouldn't
   be paying any penalty other than compiler complexity.  I am
   convinced keyword args are a big win for complex interfaces.
   Positional arguments start to lose it above 5 or 6 arguments.

One way to handle the many argument problem would be to make
keywords part of the programming environment (eg, the editor
would let you specify parameters that way) rather than having
them exist at run-time.  All parameters could then be specified
by keyword rather than positionally.  However, there would be
difficulties with APPLY (either there are keywords in the list
of arguments or else we're back to positional) and we'd be moving
towards a situation where source code wasn't readable without
the aid of some clever environment.  So in this (as in many issues),
I think CL has made a reasonable compromise.

   >[6] empty list and false still aren't distinct

True, but not as much a problem in practice as theory might indicate.

   >[7] the lack of temporary (transparent) hash-tables (c.f. Poplog CL, T) 

I agree, but there wasn't enough agreement on what the user-level
facilities should be.

   >[8] the lack of destroy actions (c.f. Poplog CL)

I think it's reasonable not to have them, although they might be
useful from time to time.  The model in Lisp is often that objects
exist forever, so they'd never be destroyed.  This model is probably
too simple, but then Lisp (even Common Lisp) is basically a simple
language.

   >[9] the poor choice of initial syntax features (defun, do) 

This is largely a matter of taste.  DEFUN and DO are in CL because
they were in MacLisp and because there wasn't a strong enough reason
to get rid of them.  Many Lisps have something like DEFUN (eg, DE)
which I don't think is a big improvement.  Some Lisp have only things
that are much worse than DEFUN.

   >[10] the dual name spaces for functions and values (bletch!)
   >(use type hints to avoid the usual complaints of efficiency 
   >(see Pop11))

One thing that I've often found strange is that some people seem
to think it's more important to have a single name space than to
have lexical scoping.  I would have thought the opposite was true.

Dual name spaces is not an efficiency issue as far as calling is
concerned, if you're willing to use up a little space and have
assignment to globals be a bit slower.  There are other reasons to
put functions in a separate name space.  I think that, on balance,
it's better to have one name space for both functions and variables,
but there is nonetheless something to be said for the other side.

But having to put in a "hint" that something was a function would be a
pain.

   >[11] type assertions are unchecked & are effectively promises
   >rather than hints (I'd like both, thanks) 

I agree that CL declarations are a problem, because in practice one
may want them for two different purposes (to check and to avoid
checking).  Some implementations (eg, CMU CL) seem to handle this
well.

But how is a "hint", if it does anything, different from a "promise".
(It's certainly not obvious just from the name "hint", which is all
I know about them.)

   >[12] the lack of a updaters (see Pop11) for an update model that
   >can support abstraction (SETF is a compile-time thing).

I agree that something like this is a good idea.  (See previous messages.)

-- jeff