Path: utzoo!attcan!telly!lethe!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: Greatly exaggerated reports of Lisp's demise
Message-ID: <4121@skye.ed.ac.uk>
Date: 13 Feb 91 14:03:32 GMT
References: <1991Feb12.122415.23035@src.dec.com>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 79

In article <1991Feb12.122415.23035@src.dec.com> meehan@src.dec.com (Jim Meehan) writes:
>I'm amazed at the recent spate of Lisp-bashing on comp.lang.lisp, and
>how few replies there have been either to defend Common Lisp or to
>explain misunderstandings in the complaints.  CL is not without its
>faults, but it ain't COBOL, either ;-)

Humm.  I've tried to defend Common Lisp to some extent and to explain
some misunderstandings.  But I also think it's useful to identify
problems so that implementors are encouraged to do something about
them.  So in a sense I'm on both sides.

>Erann Gat asked why the CL committee decided "not to include
>call-with-current-continuation."  I wasn't on the committee, but my
>impression is that 1984 Common Lisp predates call/cc, or at least it
>was thought to be difficult or expensive to implement (or that most
>CL programmers would abuse it :-), but it would be interesting to hear
>directly from them.  Of course, what's difficult one year may be less
>difficult the next; witness ephemeral GC on stock hardware.

I think there are good reasons not to have call/cc.

Scheme wants call/cc because it's a single, powerful mechanism that
subsumes a number of less general ones; and that's the kind of
language Scheme is.  Efficient implementation techniques have been
developed, and so I think the sort of progress that allowed ephemeral
GC on stock hardware has to a large extent already occurred.

However, the presence of call/cc does make it harder to say that some
dynamic context has definitely been exited.  This has a number of
consequences, such as making it less clear how dynamic scoping should
work and making certain idioms less reasonable to use.  For example,
it's common to nreverse a result, but what if the function that
produced it might return more than once?  (This observation about
nreverse / reverse! is not original with me; I got it from a talk by
Will Clinger or someone at the Snowbird L&FP conference.)  

So there are certain conceptual and practical consequences of call/cc
apart from direct efficiency issues.  I think it's more reasonable
to have such a construct in Scheme than in CL.

>But it would not trouble me to see call/cc added.  It does trouble
>me to see the new LOOP macro added.  It's yet another embedded
>sublanguage (FORMAT is another one, perhaps "the" other one).  But maybe
>the obvious thing for the committee to do is to formalize the notion
>of libraries: collections of functions, macros, and global variables
>that serve particular needs, so that if you don't want them, you don't
>pay for them. 

Another approach might be for implementations to do this.  Some people
think they can't, because CL is too deeply intertwined.  I think they
are wrong.

>Of course, having the wealth of choices for writing the same code is
>not always a good thing.  We had an in-house "Common Lisp style sheet"

This is a good idea.  Would it be possible to have a copy?  I'd
be interested in seeing what you decided.

>On the issue of finding out what a class' instances are, or what slots
>a structure has, I'll take the hard line and say there's good reason
>NOT to provide that information.  As a couple of people have pointed
>out, you can build classes that do keep track of their instances, but
>then you have to worry about GC.  In other words, you normally don't
>want to pay for this.

I agree completely on the issue of classes that keep track of their
instances (and would make as similar point about named instances),
but I think the question of defstruct slots is different.  The amount
you have to pay is fairly small, and a number of people have had to
implement this functionality themselves.  This can be annoying when
the implementation will almost always have the information somewhere.
But this sort of problem has been greatly reduced by the addition
of CLOS.

-- jeff

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton