Alastair Reid wrote: > > John's first suggested alternative above seems very appealing to me, as it > > seems neatly to fix the fundamental design flaw in `errno`: that > > determining the success/failure of a system call is separated from the call > > itself. > > Slightly off-topic but it reminds me of one of my pet peeves with C... > > I think the design flaw is in C and that is merely reflected in the C library. > If you listen to the propaganda, C is just a portable assembly language and, > in many ways, C is just that. One of the big differences though is that in > assembly language, there is no problem returning multiple values -just load > up multiple registers or put multiple values on the stack- but in C, there is > no good way to return multiple values.
Well, you can return a structure. The main disadvantage there is that, due to C's lack of anonymous product types (tuples), you would have to define a bunch of new structure types. The other problem, namely that the caller has to separate the "real" result from the ancilliary data, is equally applicable to Haskell. E.g.: let (y, _) = f x (z, _) = g y in z or even: fst $ g $ fst $ f x are less convenient than just "g $ f x". The overhead may be worthwhile when you frequently want to use the ancilliary information but, with one exception[1], checking errno is relatively uncommon. Most of the time you only need to know that the call failed, rather than the exact reason why it failed. [1] Of those cases where you do actually check errno, IME the majority come down to checking for EAGAIN when using non-blocking I/O. IMHO, a far bigger problem is the use of distinguished return values (typically -1 or NULL in C, Nothing in Haskell) rather than exceptions. If I ever decide to switch from C to C++ for everyday use, it's more likely to be for C++'s exceptions than for it's OO support. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi