[Haskell-cafe] exceptions vs. Either

[Ketil Malde]

MR K P SCHUPKE <k.schupke at imperial.ac.uk> writes:

>> As for head, I think it's fine that it throws an error because it is
>> specified to be defined for only non-empty lists.

> But surely it is better to encode this fact in the type system by
> useing a separate type for non-empty lists.

Yes, in principle.  But that means you still need to write more and
tedious code to deal with it.  

And there's a question how far you can practically get with this
approach.  Are you going to discard lists in favor of tuples, just
because the type systems can't verify that the index passed to (!!) is
witin range?

>> A mechanism for a function to report the caller site would obliviate
>> the need for all this ugliness

> Unfortunately the cost of this is prohabative as the call stack
> would have to contain backtrace information. Also due to lazy
> evaluation the 'call site' may not be what you expect.

AFAICS, this disadvantage is shared by all other schemes of "labeling"
call sites.  The only difference is that I want to do it automatically
(perhaps when a debug option is passed to the compiler)

I don't want it for all functions or anything, just the annoying,
small, and commonly used "leaf functions".

> Here's what John Meacham had to say:

> -----------------------------------
> Note that pattern matching rather than deconstruction functions have a
> number of benefits, not just relating to error messages, consider two
> functions which use the head of their argument.

> f xs = ... head xs ...=20
> g (x:_) = ... x ...

> now, g is superior to f in several ways,=20

I agree with this.  How about constructs like

  mins = map (head.sort)

Is 

   mins = map ((\(x:_)->x).sort)

still so superior?  Is it really necessary to sacrifice code clarity
just to get decent error messages?

And how do you extend this approach to 'read' and (!!)?

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants