[530] in Coldmud discussion meeting

Re: To-Do list..

daemon@ATHENA.MIT.EDU (Sat Nov 5 13:39:29 1994 )

To: George Heintzelman <georgeh@MIT.EDU>
Cc: coldstuff@MIT.EDU
In-Reply-To: Your message of "Sat, 05 Nov 1994 11:41:52 EST."
             <9411051641.AA03780@carbonara.MIT.EDU> 
Date: Sat, 05 Nov 1994 12:56:31 EST
From: Greg Hudson <ghudson@MIT.EDU>


> Scheme's Call-with-current-continuation.  Exactly how this works is
> difficult to explain, but it basically packages up all of the
> current stack, including the 'future' of the computation in
> progress, and passes it off as an argument to the function which is
> an argument of call/cc.

I certainly hope not.  There are a number of serious problems with
call/cc:

(1) It's very confusing.  By introducing a first-class object which
contains information about the call state of the program, you allow
for all sorts of spaghetti.  Closures are bad enough, but with call/cc
it becomes just about impossible for a human to analyze the flow of a
program.

(2) It's too general.  Because call/cc returns a first-class object,
you can have a procedure return a continuation to the middle of that
procedure, store that value in an object, finish the entire task,
handle some other requests, and then have someone activate the
continuation.  This implies that the the implementation cannot be
using a stack (you have to do continuation-passing style conversion
and manage the stack on a garbage-collected heap, typically).

To a certain extent, saying "the implementation is too hard" is
begging out, but it's rare that people actually want non-local control
beyond exception-handling semantics.  I'm not even convinced that
there is a good use for resumption semantics, although unwind-protect
might not be a bad idea.  Also, when you have a multi-level memory
hierarchy, a contiguous stack has serious performance advantages.

(3) Overly general non-local control mechanisms introduce problems in
a multithreaded environment.  Suppose, for example, that I have a
thread-safe list, and I want to introduce a procedure which maps a
procedure over the values of the list in a thread-safe manner.  If
that procedure can activate some random continuation, then there's no
way I can implement locking semantics.  (Exceptions are no problem,
however; I can unwind-protect and unlock, or catch all-unlock-rethrow,
whatever.)

C-- was intended to be practical.  Let's not jump off the theoretical
deep end here.