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

Re: exception systems

From: "Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>
Subject: Re: exception systems
Date: Thu, 18 Apr 96 20:48:29 -0400

> |   Dynamic-wind might have its place, but not with call/cc.  I see
> |   call/cc as a low-level mechanism, and we all know how you get a
> |   call-with-context that does take care of dynamic-wind from a low-level
> |   call/cc.
> I'm confused about what you are saying.

The concept of a `continuation' is a very clear one -- and it doesn't
involve executing any unwinding-code.  With dynamic-wind there is code
that executes when I invoke a continuation that wouldn't have been
executed had I not captured that continuation but `returned' to it in
the usual fashion.  The `continuation' of a call/cc with dynamic-wind
simply no longer corresponds to what `continuation' used to mean when
the term was coined.

I personally have very little use for dynamic-wind (because I'd rather
avoid state altogether), and I would like to have the pristine
original call/cc around that is not loaded with the extra baggage of a
mechanism I don't care about.

> If the user is using something like dynamic-wind, then to a first
> approximation all uses of cwcc must be replaced by those of the
> version that understands the context.  Otherwise the program will not
> work.

That is correct.

> In many implementations of dynamic-wind, it is exactly one word as
> well, but it is there.

But the invocation of the so-captured continuation must first execute
the unwinding code.  call/cc might still be cheap, but the actual
`context switch' is quite heavy.

> Either way, cwcc has overhead on top of the control-structure
> collection.  Implementations trade off on this overhead in the same
> way that they trade off on the overhead of the control-structure
> collection.

In SML/NJ I don't see much overhead in call/cc.

> SML has decided to make cwcc very cheap by making everything else
> somewhat more expensive.

This is a myth.  SML/NJ's implementation strategy happens to allow a
very cheap implementation of call/cc.  It was, however, not chosen
just because of that.  Also, I don't know what you mean by `making
everything else somewhat more expensive'.  Admittedly, it is a
controversial topic, but if you look at Appel and Shao's papers on
this issue then you will see that the jury is still out.