Path: utzoo!attcan!uunet!cs.utexas.edu!rice!flora!boehm
From: boehm@flora.rice.edu (Hans Boehm)
Newsgroups: comp.object
Subject: Re: Continuations
Message-ID: <3374@brazos.Rice.edu>
Date: 3 Dec 89 17:36:40 GMT
References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <1623@odin.SGI.COM> <1989Nov28.183816.15252@odi.com> <9964@june.cs.washington.edu> <1989Nov29.225826.19483@odi.com> <10008@june.cs.washington.edu> <5153@tekcrl.LABS.TEK.COM>
Sender: root@rice.edu
Reply-To: boehm@flora.rice.edu (Hans Boehm)
Organization: Rice University, Houston
Lines: 70

In article <5153@tekcrl.LABS.TEK.COM> kend@mrloog.WR.TEK.COM (Ken Dickey) writes:

>In C you get a local/global namespace.  You don't have name scoping in
>blocks nested more than 1 deep.  That's pretty trivial.
What about:

int i;
int f()
{
    int i;
    ...
    {
	int i;
	...
    }
}

I won't argue about whether this is trivial, but there are certainly nested
scopes.

>
>>3. Continuations are orthogonal to first-class functions (e.g. languages
>>   that allow both upward and downward funargs) and are orthogonal to
>>   block structure.  It is not apparent to me that continuations are
>>   any less useful without block structure (though C and C++ have it anyway).
>>   It is also not apparent to me that continuations are any less useful
>>   without nested functions (though maybe more cumbersome).
>
>I suggest that you look at some of the Scheme literature for examples
>(e.g. Abelson & Sussman: "Structure and Interpretation of Computer
>Programs", MIT Press/McGraw-Hill, 1985).

A more specific argument would help here.  I am reasonably familiar with
the Scheme literature, and it seems to me that most of the standard
examples involving continuations translate reasonably easily into a
world without closures, though they may be much less clean.  Call/cc is
probably not quite the right primitive.  An interface closer to
setjmp/longjmp (but without the restriction on the caller to setjmp
exiting, and with a cleaner distinction of what's saved, and what isn't)
probably makes more sense.  This would certainly be adequate for
implementing coroutines and the like.  It would be similar to
Call/cc(lambda x . (jmpbuf := x; 0)) in Scheme-like languages.

Note that unlike in Scheme, there is no analog to "continuation-
-passing-style" in C/C++.  But this is orthogonal to the above
discussion.

>
>>4. C and C++ have first class functions.  Functions can be passed as
>>   parameters, returned as function values, and assigned to variables.
>
>They cannot be unnamed.  They cannot be parameterized.  They are *not*
>first class.

I'm not sure what "They cannot be parametrized" means.  For most
interpretations of the sentence, it's wrong.

I would be among the first to argue that languages should provide real
higher-order functions.  However, it also seems clear that this requires
garbage collection of one form or another.  Furthermore it removes
some control over allocation behavior from the programmer.  Both of
these in turn cause some difficulty with programs operating under severe
real-time constraints.  C and C++ chose not to go this route.  Given that
they didn't, I know of no way to implement continuations efficiently,
while sticking to the design philsophy of either language.  Thus it doesn't
make sense to me to add first-class continuations to C++.  But this
argument has nothing to do with their utility to the programmer.

Hans-J. Boehm
boehm@rice.edu


Brought to you by Super Global Mega Corp .com