David Rush  <kumo@bellsouth.net> wrote:
+---------------
| Matthias Blume <blume@research.bell-labs.com> writes:
| > The solution that jrm is proposing (that is: generating a runtime
| > error when > you enter a certain dynamic scope where you might have
| > access to a closed port) is a gross hack.
+---------------

And a non-functional one, as well! [See below.]

+---------------
| > If you are willing to rely on runtime errors, why not just wait for
| > the one you will get when you actually try to do something with the
| > closed port?!?
| 
| Or even work on providing a good mechanism to allow user-space code to
| catch and handle errors detected by the runtime system. The RnRS
| semantics for 'an error is signalled' are apalling.
+---------------

Appalling isn't *halfway* strong-enough a term!! Look very
carefully, boys & girls: There is nothing in R5RS that says
*anything* about requiring the "after" thunk of a dynamic wind
to run when "an error is signalled"!!! No interaction between
"error(s) signalled" and dynamic-wind is described AT ALL!
It is therefore perfectly permissible for an R5RS-compliant
Scheme to run some completely orthogonal exception-handling
system or abort to the top-level REPL or even simply exit --
*WITHOUT* running any "after" thunks on any open dynamic-winds.

[Nor is it required that "signalling an error" invoke any particular
continuation -- or indeed, any user-captured continuation at all --
so you can't sneak the requirement in that way.]

I say: (1) Throw out dynamic-wind; (2) either restore R4RS call/cc
or replace it with simple Scheme-level threads; (3) define a *real*
exception system (including restartable handlers) that includes all
errors that may be "signalled" and interacts reasonably with whatever
was chosen for #2.


-Rob

-----
Rob Warnock, 30-3-510		<rpw3@sgi.com>
SGI Network Engineering		<http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]