I often find myself at odds with this choice. The reason is that I use Haskell as a host for embedded languages, and these often come with their own control flows. So I find myself wanting to write my own definition of the if-then-else construct that works on terms of some other type, e.g. tests on values of type Exp Bool instead of Bool, and at the same time make sure that the user doesn't use the built-in if-then-else. Sure, I can (and do) call my own version if_, ifElse or something else along those lines, but it's sure to be a constant source of programmer errors, writing if-then-else instead of if_ by habit. A thought that has crossed my mind on several occasions is, why not make the syntactic if-then-else construct rebindable, like the do notation? I think I know the answer already -- the do notation is syntactic sugar for >>= and company so it's easy to translate it into non-prelude-qualified versions of functions with those names. This is not the case for if-then-else. But it could be, the prelude could define a function if_ (or whatever) that the if-then-else construct is made to be sugar for, and thus also amenable to rebinding by not prelude-qualifying. /Niklas On 7/27/06, Paul Hudak <paul.hudak@yale.edu> wrote:
Mike Gunter wrote:
I had hoped the "History of Haskell" paper would answer a question I've pondered for some time: why does Haskell have the if-then-else syntax? The paper doesn't address this. What's the story?
thanks, -m
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 considering the alternative, I remember the function "cond" being proposed instead of "if", in deference to Scheme and to avoid confusion with people's expectations regarding "if".
A related issue is why Haskell does not have a "single arm" conditional -- i.e. an "if-then" form, which would evaluate to bottom (i.e. error) if the predicate were false. This was actually discussed, but rejected as a bad idea for a purely functional language.
-Paul
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe