Re: call/cc?

[Jonathan Bachrach <jrb@xxxxxxxxxx>]

Neel Krishnaswami <neelk@alum.mit.edu> writes:

> Avi Bryant writes:
> >
> > A while ago there was some brief discussion about the desire to add
> > call/cc to goo.  The impression I get from, for example, the
> > pthreads-based threading, is that goo is getting increasingly tied
> > to the C stack, which would make full continuations pretty
> > unrealistic.  Does anyone else still have any interest in them?
> 
> Well, one could always use a Henry Baker "Cheney on the MTA" style
> compiler/allocator and keep both pthreads and call/cc.
> 
> http://zurich.ai.mit.edu/pipermail/info-cscheme/1994-February/000161.html
> 
> I think that in some sense this may be the right thing to do (modulo
> the caveats that come from the fact that I'm not the one implementing
> it).

it's definitely a cool hack but i'd like to point out that i feel like
this is much harder to implement and its performance is more suspect
than it might appear after first reading that paper.

baker states that it allows free C interoperability but as far as i
can tell it doesn't allow callbacks because then it would require the
gc to know the stack format and produce a new stack for those pending
c calls and to perform the necessary patch ups.  i don't know how to
do this.  what am i missing?  

the other thing it requires is a precise gc.  this is particularly
difficult when state gets put into machine registers.  one could force
local state into stack frames but this would slow things down.  the
nice thing about a conventional c back end implementation is the
convenience of the boehm garbage collector.

furthermore, there is an overhead imposed in the normal c calling
convention that makes it less efficient (in space and speed) than
usual tail calling conventions.

some of these points are made in a very interesting thesis:

  tail recursion in c by mark probst

available from 

  http://www.complang.tuwien.ac.at/~schani/diplarb.ps

there appears to be a scheme implementation called chicken which uses
this approach.

-- jonathan

> Continuations are more or less the abstract type of a first-class
> stack, and a thread is the abstract type of a first-class processor.
> Letting the OS provide concurrency seems like the right thing to me,
> and confusing the two is, well, confusing.