Sven Panne <[EMAIL PROTECTED]> wrote,
> The addendum looks fine for me, well done Manuel! But as usual, I've got a few
> minor points:
>
> * Section 3.4 (export declarations) says:
>
> "If an evaluation triggered by an external invocation of an exported
> Haskell value returns with an exception, the system behaviour is
> undefined."
>
> So far, so good... It continues:
>
> "Thus, Haskell exceptions have to be caught within Haskell and
> explicitly marshalled to the foreign code."
>
> I understand the idea here, but what about System.exitWith and
> System.exitFailure in callbacks? GHC implements this via throwing an
> exception, but this is an implementation detail IMHO. The consequence
> of this implementation choice is a fatal error (uncaught exception)
> when exit{With,Failure} is evaluated in callbacks. So there are two
> questions:
>
> * Should we allow exit{With,Failure} in such circumstances?
> (My opinion: yes)
>
> * If the answer is no, what is the "official" way to terminate
> cleanly from callbacks? Note that in the context of HOpenGL
> the callback can't return a value due to the nature of an
> external lib (GLUT). I fear that the answer could be hs_exit(),
> but that would lead to a backwards compatibility hell...
I really think that this is GHC's problem. What the FFI
report says is that the *user* cannot expect to get an
exception properly marshalled across a callback. If GHC
uses exceptions internally to implement features, which H98
doesn't define to be based on exceptions, then it is GHC's
responsibility to handle these "special" exceptions in a
special way. Overall, I guess, GHC needs to check - at
least - for exit{With,Failure} failures at callback
boundaries and handle them appropriately.
> * The example in section 5.4.2 should use "wrapper" instead of the old f.e.d.
Oops.
Cheers,
Manuel
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
