Re: non-local exits are icky
Tom Lord 28 Dec 2003 18:00 UTC
Ok, I think I better understand your attitude about non-local exits
and error signalling.
To test my understanding, and before replying to the proposal further,
let me just say back to you two things that I think you would agree
with (and think are obviously true):
1) Non-local exits to upward continuations currently afford no
general mechanism for cleanups in FFI-using C.
In particular, the "GUI example":
call chain:
scheme code captures continuation K
scheme code enters foreign binding for GUI library
GUI library invokes C callback function
C callback function calls out to scheme
scheme code invokes K
is not supported by SRFI-50. Later SRFIs will have to add
additional mechanisms to the FFI to handle such situations.
(Of course, for a limited case of using just a fixed set of
FFI-using C libraries, problems like the GUI example can perhaps
be solved at the Scheme level, mostly likely by redefining
call-with-current-continuation. The point here is just that there
is no mechanism for such problems that all FFI-using libraries can
be counted on to use -- two particular FFI-using libraries that
independently solve the problem at the Scheme level may be
difficult to combine in a single application as a result.)
2) The specification of error signalling could be made clearer:
Currently it says:
The following macros explicitly signal certain errors, and
immediately return to Scheme. Signalling an error performs all
necessary clean-up actions to properly return to Scheme,
including adjusting the stack of protected variables. Besides
that, the actual effect of signalling an error is
undefined. (It is expected that a future SRFI will deal with
the issue of handling error situations resulting from bugs in
the program.
but is could say something more like:
The following macros explicitly signal certain errors.
If an error is signalled, either:
1) the computation must be terminated
2) the computation may be continued in part by invoking
a continuation which is upwards relative to the
C call that triggered the error. (see "Calling Scheme
procedures from C".)
Other details of error signalling are unspecified by this
SRFI but are expected to be further specified in a later
SRFI.
Is that about right?
-t