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

[Simon Peyton-Jones]

GHC does indeed include the notion of "rebindable syntax".  It would be
straightforward to extend it to include if-then-else.  In effect, that
would mean that 
	if e1 then e2 else e3
would behave exactly like
	cond e1 e2 e3
including from the point of view of typing.  (You could choose a
different name than 'cond'.)  Then by importing a 'cond' with (say) type

	cond :: MyBool -> b -> b
you could use a different kind of Boolean.  You could even overload the
bool:
	cond :: Boolean a => a -> b -> b

This could be done with a few hours work.  But not a few minutes. Want
to put a feature request in Trac?

Simon

| -----Original Message-----
| From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Niklas
| Broberg
| Sent: 27 July 2006 09:01
| To: Haskell-cafe
| Subject: Re: [Haskell-cafe] Why does Haskell have the if-then-else
syntax?
| 
| 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 at 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 at haskell.org
| > http://www.haskell.org/mailman/listinfo/haskell-cafe
| >
| _______________________________________________
| Haskell-Cafe mailing list
| Haskell-Cafe at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe