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

Chris Kuklewicz haskell at list.mightyreason.com
Thu Jul 27 04:58:08 EDT 2006


Niklas Broberg wrote:
> 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

You may not realize that if-then-else is just syntactic sugar like "do".  Read 
the Haskell 98 Report

http://www.haskell.org/onlinereport/exps.html#conditionals

> Translation:
> The following identity holds:
> if e1 then e2 else e3 = case e1 of { True -> e2 ; False -> e3 }
> where True and False are the two nullary constructors from the type Bool,
> as defined in the Prelude. The type of e1 must be Bool;
> e2 and e3 must have the same type, which is also the type of the entire conditional expression.

So you could easily create a patched compiler that allows for rebindable syntax.

The fundamental syntax of "do" and "if/then/else" and patterns or guards in 
function definitions is always a case statement.

-- 
Chris


More information about the Haskell-Cafe mailing list