>>>>> "Tom" == Tom Lord <xxxxxx@emf.net> writes:

>> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

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

It pretty much is.  In fact, the SRFI has a sentence containing the
word "undefined" to describe what's going on.

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

The errors in this SRFI are all about *bugs* (the SRFI says this).

Tom> I object to the idea that the errors signalled by the draft's
Tom> primitives indicate "a bug in your [the FFI-user's] program".
Tom> SCHEME_CALL* sure looks to me like a tool for adding an extension
Tom> language to your favorite C program -- so the bug may very well be in
Tom> a Scheme extension.

Sure it may be.  But there's a bug somewhere.  This SRFI talks about
bugs that occur in the C code (even though they may originate in the
Scheme code); the point is that *all* of these things can be avoided
by proper checking before use of the facilities defined in this SRFI.

Tom> Since the underlying issue here is error-code-returns
Tom> vs. non-local-exits-past-C, while I acknowledge that you can argue
Tom> against the positive reasons for error-codes, can you please explain
Tom> why you object to them?

Because I don't think a program should be able to get away, say, with doing
(car #f).  I want a visible indication that something's wrong.  This
SRFI, as is, already gives you plenty of bullets to shoot yourself in
the foot with.  This seemed one too many.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla