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