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