David Rush <email@example.com> wrote:
| Matthias Blume <firstname.lastname@example.org> 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 Warnock, 30-3-510 <email@example.com>
SGI Network Engineering <http://www.meer.net/~rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: firstname.lastname@example.org and email@example.com aren't for humans ]