[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-local exits are icky

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