[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.




    > From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>

    > Tom> An FFI should be able to handle a situation where:

    > Tom> 	Scheme calls out to C, eventually to handle_event.

    > Tom>         handle_event calls to C, to my_hook_fn.

    > Tom>         my_hook_fn calls out to Scheme

    > Tom> Unless the GUI library I'm using has made it safe to longjmp past
    > Tom> handle_event, I can not implement this using the proposed FFI.  A
    > Tom> Scheme error underneat my_hook_fn will want to exit all the way past
    > Tom> handle_event.

    > This all hinges on your definition of "Scheme error."  The errors
    > signalled by the primitives in SRFI 50 all mean that there's a *bug*
    > in your program.  I'll admit that being able to "handle" this kind of
    > situation would be useful, but I don't even know what the right way to
    > do this would be in *Scheme*, much less in C.

Hmm.

Well, of course, we could avoid discussion of "error" and talk about
"upwards continuation" instead.

But I really don't understand your attitude here.  To be consistent,
shouldn't you simply leave error conditions completely unspecified
then?

How are you drawing this line between "error handling specifications
that are reasonable in this FFI" vs. "error handling that isn't"?

I object to the idea that the errors signalled by the draft's
primitives indicate "a bug in your [the FFI-user's] program".
SCHEME_CALL* sure looks to me like a tool for adding an extension
language to your favorite C program -- so the bug may very well be in
a Scheme extension.   It's a poor extensible program, especially an
interactive one, where an extension bug crashes the world.

I don't know how to handle errors and non-local exits "in general"
either -- but I do note some good examples of programs which mix C and
lisp that do just fine in this regard.

Since the underlying issue here is error-code-returns
vs. non-local-exits-past-C, while I acknowledge that you can argue
against the positive reasons for error-codes, can you please explain
why you object to them?   Why are non-local-exits-past-C perferable,
in your view?   Especially given that you ackowledge that C is lousy
at such idioms.

-t