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: Re: In defense of call/cc (and a plug for T)
Message-ID: <1991Feb13.055938.22853@Think.COM>
Date: 13 Feb 91 05:59:38 GMT
References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 51

In article <1991Feb12.233157.20820@elroy.jpl.nasa.gov> gat@robotics.jpl (Erann Gat) writes:
>This is a (probably) vain plea to see call-with-current-continuation
>included in common lisp.  There are a number of reasons that call/cc
>should be included.
>
>1.  It cannot be implemented in terms of existing CL constructs, so you
>can't build it even if you want to.  You can build a downward-only call/cc,
>but see the note below.

I wasn't in the original Common Lisp design group.  However, it seems
obvious that they explicitly decided against allowing upward closures to
capture control state.  Had they not made this decision, call/cc could be
implemented in terms of closures or vice versa.  I haven't read the
archives of the CL design email for about six years, so I don't remember
their justification, but I expect it was mostly along the lines of "there
isn't enough experience with it, and it doesn't really seem necessary."

>2.  It is not that hard to implement.  Including call/cc would not make
>compilers that much more complex.  All that call/cc does is copy the
>stack onto the heap.

There are some architectures where operations on the stack pointer register
are restricted, so you can't just set the stack pointer to point to a
heap-allocated activation record.

And what about the fact that call/cc makes unwind-protect more complicated;
don't you have to provide code that runs when re-entering the environment?
This means that the addition of upward control closures would not be
transparent to implementors of many macros (e.g. WITH-OPEN-FILE would have
to be changed to save its state in the closure and reopen the file and seek
to the saved place upon re-entry).

>3.  Call/cc makes it INFINITELY less painful to write coroutines.  

So do the Lisp Machine's stack group facility, and I expect some other
Common Lisp implementations provide similar mechanisms (Lucid and Franz
support multitasking within Lisp, in a manner very similar to Symbolics's).

What if we were to add a coroutine facility, rather than a primitive for
building coroutines?  See my previous posting, where I mentioned that we
prefer to define user-oriented facilities, rather than implementor-oriented
primitives.  Additionally, by defining the high-level facility rather than
the low-level mechanism, we allow implementors to tailor the implementation
to the environment (e.g. Lisp Machine coroutines would use the
hardware-supported stack group mechanism), rather than forcing the user to
implement the facility using suboptimal primitives.
--
Barry Margolin, Thinking Machines Corp.

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