Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sunybcs!sbcs!allen
From: allen@sbcs.sunysb.edu ( Allen Leung @ SUNY at Stony Brook, L.I., NY )
Newsgroups: comp.object
Subject: Re: Continuations
Message-ID: <4127@sbcs.sunysb.edu>
Date: 3 Dec 89 20:00:51 GMT
References: <2664@bingvaxu.cc.binghamton.edu> <9624@pyr.gatech.EDU> <3374@brazos.Rice.edu>
Sender: news@sbcs.sunysb.edu
Lines: 90

In article <3374@brazos.Rice.edu>, boehm@flora.rice.edu (Hans Boehm) writes:
> 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.

   True, C has nested scopes, but only with non-functions.  We certainly
can't write 
   int i;
   int f()
   {
       int i;
       int g()
       {
        ... i ...
       };
       ...
   }

When we disallow local declaration of functions, I think all the sub-blocks 
can be lifted up to the main block with proper renaming of bound variables
( If you treat sub-blocks as lambda expression with a throw-away parameter, 
then they can always be beta-reduced at compile time. ) 
C with nested scopes actually has no more power( not the Turing Machine sense) 
than one without, even though its more convenient.  


> 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.

    Maybe the original author means that C functions cannot reference non-global
free variables.   
    In any case, I'm extremely doubtful that continuation in a 
language with *side-effects* can be translated easily into a language 
without the concept of a closure.  Since a continuation is essentially a 
closure( entrypoint + environment ).  
    A language with side effects complicates the implementation of
closure/continuation tremendously:  A variable must reside in 
one place, either on the stack or in the heap; any duplication
will make the variable's update non-trivial.  
    I'm not familiar with Scheme, but I guess it only *solves* this
problem by allocation the stack frame of a possibly 'closurised'( you know
what I mean ) code on the heap, similar to what most lisp do with a upward 
funarg( or is it downward? I can never remember which is which.) 

    A language that supports continuation must/should support
first-class/higher order functions.  They have about the same complexity.
I believe we can simulate continuation with higher order functions
easily enough.  A continuation is just a function that never returns;  
that "never returns" part have some problem related to stack allocation, 
of course.

allen@sbcs.sunysb.edu


Brought to you by Super Global Mega Corp .com