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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 | > | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe