Rabbit

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   Date: Thu, 13 May 93 14:37:03 BST
   From: Jeff Dalton <jeff@aiai.edinburgh.ac.uk>

   >       From: shivers
   >       That's because CALL/CC doesn't distinguish these things. It's too damn
   >       powerful. I do not like CALL/CC. It messes up my foundations for
   >       reasoning about programs. And if it interferes with human reasoning,
   >       that goes double for compiler analysis.
   > 
   >    From: jaffer
   >    In Steel's 1978 Thesis on the Rabbit (optimizing) compiler, he uses
   >    continuation-passing-style lambda as the compiler's intermediate form.
   >    Although call-with-current-continuation was not part of Scheme at that
   >    time it clearly would have been trivially handled by the compiler.  So
   >    I don't think any problems your compiler is having with CWCC are
   >    universal.

   I'm pretty sure Rabbit handled a similar form called CATCH.  But I'm
   also pretty sure CATCH was a special form.  CALL/CC could presumably
   be defined using CATCH, but whether all of the CATCH optimizations
   could still be done is less clear.  On the other hand, there must be 
   more recent compilers that take the Rabbit approach of converting
   to continuation-passing style, and they will handle CALL/CC directly.

You are correct that a special form is much more easily handled than
the procedure CWCC.  Many scheme compilers have a way to declare that
a variable's value does not change.  In this case, occurences of CWCC
in combinations can be treated as a special form.

My opinion is that CWCC and APPLY should be syntactic constructs.  A
procedure version of these can be trivially written if it is needed.
It is unfortunate accident that CWCC and APPLY can be specified as
procedures.  They are control constructs just like LAMBDA and
combinations.

   Nonetheless, I agree that CALL/CC is too powerful.  I would rather
   have coroutines/stack-groups or lightweight processes that CALL/CC
   even though (indeed, in part becuase) they are less general.

There seem to be two positions being expressed on this issue:

<1> CWCC is the pure CS notion of continuation by which all other
control constructs can be expressed.  DYNAMIC-WIND needs to be somehow
restricted to actions which do not interfere with co-routine calls.
Unwind-protects which do things like closing files need to be
implemented some other way.

<2> CWCC is too powerful.  It should be split into several different
constructs to express co-routines, multi-processing, escapes, process
copying, etc.  DYNAMIC-WIND will affect only some of these.

In order for <2> to have the same power that CWCC currently does, we
would need to add many constructs.  Does anyone have a list of
mutually exclusive control constructs which cover CWCC, or even just
all useful control constructs?

All position <1> needs to fix DYNAMIC-WIND is a statement to be
incorporated into the description of DYNAMIC-WIND.  I suggest "The
<before> and <after> arguments to DYNAMIC-WIND should have actions
which are the reverse of each other."  Does this fix it?