[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