Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Common Lisp gripes (was Re: In defense of call/cc (and a plug for T))
Message-ID: <1991Feb17.000333.16922@Think.COM>
Date: 17 Feb 91 00:03:33 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov> <1350036@otter.hpl.hp.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 68

In article <1350036@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes:
>PS. My own personal gripes with CL are [1] the type system is far too loose

We're tightening it up a bit in the ANSI version.

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

X3J13 has cleaned up EQUAL and EQUALP a little.  However, our general
feeling is that it's not really worthwhile to spend lots of time on the
built-in equality predicates.  Equality is generally a domain-specific
notion, and simplistic equality predicates are rarely applicable.  For
instance, should EQUAL recursively descend into defstruct slots?  The
answer generally depends on the semantics of the structure.

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

What cost is there for them when you don't use them?  There doesn't need to
be much cost for the fact that standard functions have keyword arguments,
because the compiler can transform calls to them into calls to non-keyword
versions.  The only exception is when the argument list is not known at
compile time (i.e. FUNCALL or APPLY is being used), but these are the
situations when the keyword argument list is most useful, so the expense of
parsing the keywords is worth it (IMHO).

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

I don't think this is considered a bug in the CL community.  Even Scheme
has only very recently changed this.

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

What efficiency complaints are these?  I think most of us who are in favor
of multiple namespaces (there are more than two -- there are also namespaces
for classes, types, and packages) like the semantics of it.  I've never
heard an efficiency justification.

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

It's easy to write a macro that combines a type declaration and a type
check.  Something like

(defmacro with-type ((variable type) &body body)
  `(progn
     (check-type ,variable ,type)
     (locally
       (declare (type ,type ,variable))
       .,body)))

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

ANSI CL will allow you to define a function named (SETF <symbol>).  If SETF
doesn't recognize the first subform as a macro-style setf method, it turns
the SETF call into (FUNCALL #'(SETF <symbol>) ...).

By the way, did you ever make your complaints known to HP's representative
to X3J13 (sorry, I don't remember who that is)?
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar