Re: [Haskell-cafe] exceptions vs. Either

Yes, in principle. But that means you still need to write more and tedious code to deal with it.
Just because code is tedious does not mean it is not necessary to handle all corner cases. A robust application does not fail when given unexpected input.
Are you going to discard lists in favor of tuples,
Of course not... You can actually define constrained datatypes where the maximum length is a parameter of the type. Unfortunately in haskell because these values have to be at the type level we end up encoding them as Peano numbers... See Conor McBrides "Faking It" paper for some examples of how to do this. Also see Oleg, Ralf and My paper "Stronly Typed Heterogeneous Lists" to se how far you can get with these techniques (we define a heterogeneous list that can be constrained in many ways, including by length, or content type). I guess in a way you are nearly right as these techniques fundamentaly us binary products like (,) - but thats also exactly what any binary constructor including ':' is anyway...
The only difference is that I want to do it automatically
My point was that you can manually label some functions, but to automatically do it for all functions is going to cause big stack space problems - think about recursive functions... or mutually recursive functions... Keean.

MR K P SCHUPKE
mins = map ((\(x:_)->x).sort)
maybe what you meant was:
case sort x of (x:_) -> ... do whatever with x ... _ -> ... do failure conition ...
No, I don't think so. I only want the bug to be reported, and the umatched pattern will do it nicely.
Yes, in principle. But that means you still need to write more and tedious code to deal with it.
Just because code is tedious does not mean it is not necessary to handle all corner cases. A robust application does not fail when given unexpected input.
But if I use head, I should *know* that I never pass it an empty list. Whether head returns a Nothing or just crashes doesn't matter, I have to go and fix my *design*, because it has a bug, and not a "corner case" that should be "handled".
Are you going to discard lists in favor of tuples,
Of course not... You can actually define constrained datatypes where the maximum length is a parameter of the type.
The only difference is that I want to do it automatically
My point was that you can manually label some functions, but to automatically do it for all functions is going to cause big stack space problems - think about recursive functions... or mutually recursive functions...
Yes, of course. So *my* point is that it would be really nice to write small leaf functions like these with an implicit file/line parameter that identified the caller site, in order to avoid cluttering the code with them. Okay, perhaps I'm not using the type system to its full extent, but I think this is fairly common practice. An easy solution seems to be to use -cpp and add #define head (\(x:_)->x) at the top of the relevant source files. However, I'm not sure how to make this work with the other difficult functions. Another alternative (basically emulating the GHC's behavior in the above case) is #define head (\x -> case x of {(x:_) -> x; _ -> error ("head failed at "++__FILE__++":"++ show __LINE__)}) It seems difficult to generalize this, though. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (2)
-
Ketil Malde
-
MR K P SCHUPKE