Re: exception systems

["Guillermo J. Rozas" <gjr@martigny.ai.mit.edu>]

|   Date: Fri, 19 Apr 1996 10:21:53 -0400
|   From: Matthias Blume <blume@CS.Princeton.EDU>
|
|   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.

There is only unwiding code if the dynamic state has changed.  If it
hasn't, and typically a simple pointer comparison suffices, there is
no additional code to execute.

Even in SML you have to re-instate the exception register, and perhaps
(I don't know much about SML exceptions), do something else on top.

|
|   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.

Yes, but if you happen to use a library (e.g. basic I/O) that uses
dynamic-wind unbeknownst to you, you will get in trouble.  That is why
the language primitive (noot the subprimitive hidden somewhere inside
the implementation) must support it, just like the SML primitive
supports exceptions.
|
|   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.
|

Often ist is a simple pointer comparison, since no dynamic state has
changed, especially if you are not using it.

|   > 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.

Nor much else in Scheme, if you are not using dynamic state.  If you
are, you pay for it one way or another.
|
|   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.

We can discuss this ad infinitum, but it is not a myth.  SML made one
choice.  I would not make it for many reasons.  That's OK, I'd rather
have implementations that take very different tacks, we learn
something from the diversity.