Re: The Errno Story

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]>