Sven Panne <Sven.Panne@informatik.uni-muenchen.de> 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