Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!news
From: matthias@leto.rice.edu (Matthias Felleisen)
Newsgroups: comp.lang.lisp
Subject: Re: In defense of call/cc (and a plug for T)
Summary: specific control structures for specific problems
Message-ID: <1991Feb18.041425.5764@rice.edu>
Date: 18 Feb 91 04:14:25 GMT
References: <1991Feb13.055938.22853@Think.COM> <1991Feb14.223202.11475@elroy.jpl.nasa.gov> <4140@skye.ed.ac.uk>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 49
Cc: gls@think.com, dfried@iuvax.cs.indiana.edu

Let me try to reformulate Erann's plug for call/cc. 

During the design of a programming language, it is impossible to
anticipate all needs for functions. Therefore we build in LAMBDA so
that programmers can define their own functions. It is also impossible
to foresee the kinds of data, programmers will have to deal with.
Languages therefore include tools for structuring data in some form or
another. And, in the same vein, it is just as impossible to project
the sort of control abstractions a programmer would like to have
around.

The most natural solution is the inclusion of a powerful control
construct such that programmers can build a set of control
abstractions for specific problems with a set of macros.  With call/cc
and first-class continuations (for example), it is easy to implement
  <> generators,
  <> Prolog-style backtracking, 
  <> non-blind backtracking, 
  <> all kind of coroutine models, 
  <> system trap doors (see the SML/NJ compiler),
  <> engines (with a timer or by redefining lambda and set!),
  <> operating systems (in conjunction with engines), 
and a few more. And that on top of all the control constructs in
Common Lisp. 

The disadvantage of building a specific high-level control construct
into a language is two-fold. First, and again, there are too many.
Every recent language from Icon via ML to Prolog has its own (or
several). Clearly, all of them were thought to be useful; otherwise
they wouldn't be in these languages. Second, a specific control
construct comes with a specific programming paradigm, and when
thinking about something else it is difficult to think of using it in
non-standard ways. Yes, FIRST-CLASS coroutines can be used to define
call/cc and therefore other control constructs.  BUT, who would think
of doing so?  Schemers, on the other hand, are trained to think of
call/cc as the tool to implement the control construct that is best
for a given problem and their way of thinking about it.

Restricting the programmer's tool for thinking about problems is
wrong: Life is too short to waste hours and days just because some
committee wanted to save some cycles and some pain for implementors.

I'd love to see the CL committe correct this mistake by the time CLtL3
comes around. Perhaps we could get call/cc PLUS a set of high-level
control constructs just like we got lambda PLUS a huge library of
functions, def-macro PLUS a number of standard macros, cons and
vectors and types PLUS CLOS, etc. Guy, any chances?

-- Matthias Felleisen