[Haskell-cafe] Haskell and the Software design process

[wren ng thornton]

Rafael Cunha de Almeida wrote:
> I don't think that safeSecondElement is worse than secondElement. I think it's
> better for the program to crash right away when you try to do something that
> doesn't make sense.
> 
> Getting the secondElement of a list with one or less elements doesn't make
> sense, so you are definetely doing something wrong if you expected the list to
> have two elements, but it doesn't. It's best that the program crashes there,
> than propagate the error and crash somewhere else or, worse, not crash at all
> and give a wrong answer.

There are two different issues at stake here, one is reactive and the 
other is proactive. You're responding to the reactive question: how do I 
deal with unexpected errors when they arise? But those who argue against 
partial functions are usually responding to the proactive question: how 
do I prevent unexpected errors from arising in the first place?

By allowing partial functions we allow for the introduction of 
unexpected errors, which then forces us to handle the reactive question 
of what to do when those errors show up. But if partial functions are 
avoided, then there are no unexpected errors (of that sort) which could 
ever show up.

We already have to deal with bottom, that's a fact of life for 
general-purpose programming. But partial functions allow us to introduce 
bottom in new ways. When we have bottom meaning just non-termination, 
then we have a good idea about how we should treat it. But once we start 
introducing other bottoms for things like non-exhaustive pattern 
matching or recoverable exceptions, then it's no longer clear what 
exactly bottom means. This in turn makes it hard to know whether the 
semantics of the program match the semantics we want. In particular, I'm 
a fan of semantics which say my program will not crash. Sure, crashing 
is better than silently corrupting everything; but not crashing is 
better than crashing.

-- 
Live well,
~wren