This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
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