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: <4140@skye.ed.ac.uk>
Date: 15 Feb 91 14:28:39 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov> <1991Feb13.055938.22853@Think.COM> <1991Feb14.223202.11475@elroy.jpl.nasa.gov>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 43

In article <1991Feb14.223202.11475@elroy.jpl.nasa.gov> gat@forsight.jpl.nasa.gov (Erann Gat) writes:

>CL has actually gone above and beyond the call for being all things to all
>people.  However, its philosophy of catering to users rather than implementors
>leads to one extremely annoying side effect.  If the thing you want to do
>just happens not to be one the ten zillion things that CL does, then you
>are just screwed.  Examples of such things appear in this group regularly -
>things like coroutines or accessing the slot names of a structure.

But this is always a problem.  There are things I want to do in
Scheme that I can't do (eg, define a distnct data type).  But
the situation is usually much worse in languages outside the Lisp
family.  Common Lisp is already better than most languages in
this respect, and I don't think it's actually much worse than
Scheme.

Moreover the examples that appear in this group regularly seem fairly
few in number.  

>What I do not understand is why you can't do both: first start with a set
>of primitives.  Define the hell out of them so everyone agrees what they do.
>Then build all the user features on top of the primitives.  It seems to me
>that this gives you the best of all possible worlds. 

I agree that this is a good approach.  But (as I've been saying with
tiresome regularity), Common Lisp can be seen that way to a surprising
extent.  It's just that lots of user features are presented, implemented,
etc as "part of the language".  

>Therefore, the answer to the original question is that I would rather
>have call/cc than coroutines.  Tomorrow I might want to build engines
>(a really cool construct that somehow got lost in the shuffle).  If I
>have call/cc I can do it myself. 

You can?  That's not what happens in Kent Dybnig's book.  He needs
an additional primitive, timer interrupts.

However, I agree that it's important to have powerful primitives
on which other abstractions can be built.  This is one reason I
don't quite agree with the user/implementor distinction.  In Lisp,
users often _are_ implementors.

-- jd