Email list hosting service & mailing list manager


Re: non-local exits are icky Michael Sperber 03 Jan 2004 16:16 UTC

>>>>> "Tom" == Tom Lord <xxxxxx@emf.net> writes:

Tom> To test my understanding, and before replying to the proposal further,
Tom> let me just say back to you two things that I think you would agree
Tom> with (and think are obviously true):

Tom> 1) Non-local exits to upward continuations currently afford no
Tom>    general mechanism for cleanups in FFI-using C.

Yes.

Tom>    Later SRFIs will have to add
Tom>    additional mechanisms to the FFI to handle such situations.

Yes, provided that they are necessary.  I'm not convinced they are,
but that's irrelevant here.

Tom> 2) The specification of error signalling could be made clearer:

That's probably true.

Tom>    but is could say something more like:

Tom>         The following macros explicitly signal certain errors.
Tom>         If an error is signalled, either: [...]

That's arguable, but not what I intended.  What I intended was that
the "an error is signalled" means the same thing as in R5RS, whatever
that is for a given Scheme implementation.  In particular, what you
propose ...

Tom>           1) the computation must be terminated

Tom>           2) the computation may be continued in part by invoking
Tom>              a continuation which is upwards relative to the
Tom>              C call that triggered the error.  (see "Calling Scheme
Tom>              procedures from C".)

... seems to leave as much room for interpretation as what's in there now.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla