Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: In defense of call/cc (and a plug for T)
Message-ID: <1991Feb15.081259.797@Think.COM>
Date: 15 Feb 91 08:12:59 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov> <1991Feb13.055938.22853@Think.COM> <PCG.91Feb14184024@odin.cs.aber.ac.uk>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 54

In article <PCG.91Feb14184024@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>Closures are completely orthogonal to continuations; closures allow you
>to actualize an arbitrary context graph, instead of a context tree
>linearized onto a stack or multiple stacks. 

All I know is that I've implemented call/cc using Common Lisp closures.
It looks something like this:

(defun call/cc (function)
  (funcall function #'(lambda (x) (return-from call/cc x))))

It would even work if Common Lisp allowed returning from a block multiple
times; the implementation of closures would have to include continuations.

>					     Incidentally, fully general
>closures also obviate the need for packages.

I've seen all the arguments to this effect, and remain unconvinced.  Common
Lisp packages can be used for other things besides bindings.  Symbols are
often used as data objects, e.g. as indicators on property lists, and
packages can be used to prevent these from colliding.

>barmar> I haven't read the archives of the CL design email for about six
>barmar> years, so I don't remember their justification, but I expect it
>barmar> was mostly along the lines of "there isn't enough experience
>barmar> with it, and it doesn't really seem necessary."
>
>This would be really surprising. The technology for arbitrary control
>and context graphs has been known for a long time (twenty five years at
>least, and it has been fifteen years since the more or less definitive
>works of Baker and Steele). Closures and continuations have also been
>extensively used in the AI community, under various guises. It can be
>argued that objects and actors and frames are just some of these guises.

And in the mid-80's, when Common Lisp was being designed, all these were
still hot *research* topics.  They hadn't yet passed into common day-to-day
use by Lisp programmers.  None of MacLisp, Lisp Machine Lisp, nor Interlisp
had them.  Yes, I realize that this is also true of lexical closures, but I
guess these were felt to be so obviously right and relatively easy to
implement that they were added.

>In other words you are saying that CL is by design a "programming"
>language, like PL/1 or PERL, not an algorithmic language like Scheme or
>C or the Bourne shell.

You've got it.  The charter of X3J13 is to produce a specification for an
industrial-strength Lisp dialect.  Usability for research into programming
paradigms is not a goal of the Common Lisp project; it *is* a high priority
of the Scheme designers.  Different strokes for different folks.
--
Barry Margolin, Thinking Machines Corp.

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