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

[Miroslav Silovic]

Marius Vollmer <address@hidden> writes:

> Miroslav Silovic <address@hidden> writes:
> 
> > Something like this:
> > 
> > (let ((object-you-have-to-clean-up (make-the-object)))
> >    (call-with-escaping-continuation
> >       (lambda () 0) ; do nothing
> >       (lambda () (destroy object-you-have-to-clean-up))))
> 
> So you propose to fold call/ec and escape-protect into one function?
> What does your two-argument call-with-escaping-continuation do?  Can
> you show an implementation in terms of call/cc and dynamic-wind?

Er, no, this is just a code example, necessary to justify my question.

> > Once the first thunk completes, should the second thunk execute?
> > [...]
> 
> Yes, it should.  The code I posted behaves this way.

Okay. I agree with that. So...

> > If yes, well, the first thunk could've saved some reenty point and
> > then call-with-escaping-continuation will bomb once it reenters.
> 
> Hmm, I'm afraid I still don't get it.  I think a implementation of
> your ideas will help me understand.  What are you proposing?  Should
> we not consider adding call/ec and escape-protect?  Should we add
> them, but with different semantics from the code I showed?

Basically I'm still unsure if call/ec gains anything, compared to
dynamic-wind that just signals an error from its setup thunk if it's
reentered.

It seems good if call/cc is used to escape from within call/ec but
there is some way to *ensure* that the execution will return inside
call/ec (because otherwise you miss the cleanup).

-- 
How to eff the ineffable?