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.
>>>>> "Tom" == Tom Lord <lord@xxxxxxx> writes: >> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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