guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Procedure proposal: call-with-escape-procedure


From: Marius Vollmer
Subject: Re: Procedure proposal: call-with-escape-procedure
Date: 06 Mar 2001 13:41:44 +0100
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

Martin Grabmueller <address@hidden> writes:

> > From: Marius Vollmer <address@hidden>
> > Date: 06 Mar 2001 02:34:37 +0100
>  
> On the long term, I would really like to see that exceptions are
> somehow implemented as GOOPS classes, [...]

Yes, agreed.  But this is an issue for another discussion, I'd say.
 
> > The important thing here is that continuations created by call/cc
> > do not run the escape handlers established by escape-protect.
> 
> Why not? Because `escape-protect' is just for cleanup?

Yes.  Call/ec together with escape-protect offer more traditional
semantics compared to call/cc and dynamic-wind.  From what I gather,
people wantg to have something like this, where they can be sure that
a certain piece of code is guaranteed to run, even in the presence of
non-local exits, and they expect this code to run only once.  This is
not the semantics they get from call/cc and dynamic-wind.

Call/e and escape-protect are intended to allow people to pretend that
this new-age thing call/cc does not exist and feel safe, more or less.

Escape-protect does not guarantee that the leave thunk is run when the
flow of control leaves the body (using call/cc) and never returns.  It
also doesn't guarantee that no part of the body is executed more than
once.  The last guarantee can hopefully be ensured by only calling
functions in the body that promise not to return more than once.

In effect, the body of a escape-protect can be suspended and resumed
without violating its assumptions, but doing more to it is unsafe.

> I don't claim to understand all possible semantic implications, but
> as call/ec is included in the suggestion, I am happy with that.  But
> of course I am interested in the `implement them efficiently' part,
> because that got the whole thing started ;-)

Yeah, got carried away, sorry.  Your original implementation seemed
fine.  But in the light of all this, I would not want to add it to
Guile until we know what it will do precisely.  Your implementation
seems easy enough that you can just put it into the programs that
needs it, right?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]