Re: continuation efficiency

[Marius Vollmer]

address@hidden (Thomas Bushnell, BSG) writes:

> Marius Vollmer <address@hidden> writes:
> 
> > address@hidden (Thomas Bushnell, BSG) writes:
> > 
> > > Marius Vollmer <address@hidden> writes:
> > > 
> > > > Actually, I think we should have call/ec as a builtin.  
> > > 
> > > If call/ec is not already a builtin, how is it actually faster than
> > > call/cc?
> > 
> > It uses a different algorithm.  Right now, it needs to be implemented
> > in terms of catch/throw, but I'd say that it should be the other way
> > around, catch/throw should be implemented in terms of call/ec, and
> > call/ec is mostly like call/cc except that it skips the expensive bits
> > and makes sure that this doesn't hurt you.
> 
> If it's not a builtin, what different algorithm does it use?  

It uses, effectively, setjmp/longjmp without copying the stack.
Call/cc uses setjmp/longjmp with copying the stack.

Or put differently, the semantics of call/ec allow optimizing the
stack copy away without needing to do global analysis.

The current interface to setjmp/longjmp without stack copying is
catch/throw.  That's why I used them in the first implementation of
call/ec.  The second implementation using call/cc was only to nail
down the semantics.  When implemented for real, the stack copying can
be optimized away again.

Here is the first implementation again:

    (define (call/ec proc)
     (let ((tag (gensym)))
       (catch tag
         (lambda () (proc (lambda (val) (throw tag val))))
         (lambda (tag val) val))))

when implemented with the extended semantics of running escape-protect
handlers, it would directly work with the dynamic wind chain without
relying on the dynamic-wind procedure (and thus call/cc).