Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.lisp Subject: Re: In defense of call/cc (and a plug for T) Message-ID: Date: 14 Feb 91 18:40:24 GMT References: <1991Feb12.233157.20820@elroy.jpl.nasa.gov> <1991Feb13.055938.22853@Think.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 71 Nntp-Posting-Host: odin In-reply-to: barmar@think.com's message of 13 Feb 91 05:59:38 GMT On 13 Feb 91 05:59:38 GMT, barmar@think.com (Barry Margolin) said: barmar> I wasn't in the original Common Lisp design group. However, it barmar> seems obvious that they explicitly decided against allowing barmar> upward closures to capture control state. Had they not made barmar> this decision, call/cc could be implemented in terms of closures barmar> or vice versa. This would a be a misdesign. The point about call/cc is that allows you to actualize an arbitrary control graph, instead of a control tree linearized onto a stack (usual case) or on multiple stacks (coroutines as stack groups). 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. Incidentally, fully general closures also obviate the need for packages. 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. As to being necessary, both are simply indispensable; you need both arbitrary context and control graphs in all algorithms that deal with non trivial graph walking, or equivalents. Many programmers do not realize this, they keep reimplementing closures and continuations "manually", simulating closures usually with bunches of global variables and continuations with state machines or "markers". barmar> And what about the fact that call/cc makes unwind-protect more barmar> complicated; don't you have to provide code that runs when barmar> re-entering the environment? Of course! When you have a control graph and a context graph, you want fully general entry and exit functions, not just exit functions. Actually you want them in general, except that they are hidden as "initialization" code. Fully general entry and exit functions are incredibly useful abstractions, because allow clean and flexible modularization and "advising" of code. I remember having read (either in Allen's book or in Baker's paper on shallow binding) that the only known language with fully general entry and exit functions is TECO, of all things :-). barmar> What if we were to add a coroutine facility, rather than a barmar> primitive for building coroutines? See my previous posting, barmar> where I mentioned that we prefer to define user-oriented barmar> facilities, rather than implementor-oriented primitives. 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. This philosphy is one of the reasons why CL is perceived as a jumble sale of features, a giant and monolithic entity. Coupled with the weak or otherwise vastly underexploited library facilities, and to the tradition to implement Lisp (and even more regrettably, Scheme) in a workspace based way, with little interaction with other host system modules, and we have a fatal combination. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk