[Haskell-cafe] Why does Haskell have the if-then-else syntax?

[Tomasz Zielonka]

On Thu, Jul 27, 2006 at 10:22:31AM +0100, Jon Fairbairn wrote:
> On 2006-07-27 at 01:33EDT Paul Hudak wrote:
> > Thanks for asking about this -- it probably should be in the paper.  Dan 
> > Doel's answer is closest to the truth:
> > 
> >     I imagine the answer is that having the syntax for it looks nicer/is
> >     clearer. "if a b c" could be more cryptic than "if a then b else c"
> >     for some values of a, b and c.
> > 
> > except that there was also the simple desire to conform to convention 
> > here (I don't recall fewer parentheses being a reason for the choice). 
> 
> In a sense, it explicitly wasn't: I suggested "if _ then _
> else _ fi" -- something I was long used to from Algol68 --
> but it was rejected on the ground that there wasn't a
> dangling else problem in Haskell.

But because if-then-else is an expression, there is another
problem. Consider:

(if True then 0 else 1) + 2             --> 2
if True then 0 else 1 + 2               --> 0
let cond a b c = if a then b else c
cond True 0 1 + 2                       --> 2   -- different from if-then-else withouth parentheses

It's quite easy to fall in this trap. I think it happened to me
at least twice. It goes like this: first I have an expression
that doesn't involve if-then-else, eg.

    a + b

Then I realize that "a" has to be changed in some situations,
so I replace it with a conditional expression:

    if c then a else a' + b

or

    if c then f a else g a + b

But now " + b" gets under the "else" branch.

If I used a "cond" function, or if if-then-else had a different
priority, it would be easier to avoid such a mistake. There is no
problem with the first version:

    cond c a a' + b

For an experienced Haskell programmer it's obvious that function
application has a higher precendence than addition.

In the second version, it would be clear that parentheses have
to be added:

    cond c (f a) (g a) + b

Could the "cond" function encourage other kinds of bugs? I think
it's less likely, because it's a normal function.

Also, after a few years of Haskell programming, I am still not
sure how to indent if-then-else.

Perhaps in Haskell' we could have some lightweight case-of version with
no pattern matching, guards only ("cond" could be a good name). I think
it was even discussed before. The usual case-of looks like this:

    case x of
        Left err | isEOFError e -> ...
        Left err -> ...
        Right result -> ...

"cond" would involve no pattern matching, or only as pattern guards.

    cond
        x == 0 -> ...
        x == 1 -> ...
        otherwise -> ...

currently it can be written as

    case () of
        _ | x == 0 -> ...
        _ | x == 1 -> ...
        _ | otherwise -> ...

which is a bit ugly.

Best regards
Tomasz