On Jul 26, 2006, at 6:44 PM, Sebastian Sylvan wrote:

For example ...

if :: Bool -> a -> a -> a if True t _ = t if False _ e = e

-- example usage myAbs x = if (x < 0) (negate x) x

I suppose there might also be a case for flipping the arguments about like this: if :: a -> a -> Bool -> a if t _ True = t if _ e False = e This way it would follow foldr more closely, in recognition that the conditional is essentially the fold/cata/eliminator/... for booleans. But argument order is a pretty trivial thing, and I think the committee made the right choice with if-then-else as a language construct. -- Fritz

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.

Wouldn't this cause a conflict with specialized knowledge the compiler has about if-then-else, e.g. for optimizations? Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: tom.schrijvers@cs.kuleuven.be

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@haskell.org [mailto:haskell-cafe-bounces@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 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

On Thu, Jul 27, 2006 at 10:22:31AM +0100, Jon Fairbairn wrote:

On 2006-07-27 at 01:33EDT Paul Hudak wrote:

...

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 a sense, it explicitly wasn't: I suggested "if _ then _ else _ fi" -- something I was long used to from Algol68 -- but it was rejected on the ground that there wasn't a dangling else problem in Haskell.

But because if-then-else is an expression, there is another problem. Consider: (if True then 0 else 1) + 2 --> 2 if True then 0 else 1 + 2 --> 0 let cond a b c = if a then b else c cond True 0 1 + 2 --> 2 -- different from if-then-else withouth parentheses It's quite easy to fall in this trap. I think it happened to me at least twice. It goes like this: first I have an expression that doesn't involve if-then-else, eg. a + b Then I realize that "a" has to be changed in some situations, so I replace it with a conditional expression: if c then a else a' + b or if c then f a else g a + b But now " + b" gets under the "else" branch. If I used a "cond" function, or if if-then-else had a different priority, it would be easier to avoid such a mistake. There is no problem with the first version: cond c a a' + b For an experienced Haskell programmer it's obvious that function application has a higher precendence than addition. In the second version, it would be clear that parentheses have to be added: cond c (f a) (g a) + b Could the "cond" function encourage other kinds of bugs? I think it's less likely, because it's a normal function. Also, after a few years of Haskell programming, I am still not sure how to indent if-then-else. Perhaps in Haskell' we could have some lightweight case-of version with no pattern matching, guards only ("cond" could be a good name). I think it was even discussed before. The usual case-of looks like this: case x of Left err | isEOFError e -> ... Left err -> ... Right result -> ... "cond" would involve no pattern matching, or only as pattern guards. cond x == 0 -> ... x == 1 -> ... otherwise -> ... currently it can be written as case () of _ | x == 0 -> ... _ | x == 1 -> ... _ | otherwise -> ... which is a bit ugly. Best regards Tomasz

Jon Fairbairn wrote:

On 2006-07-27 at 13:01+0200 Tomasz Zielonka wrote:

...

Also, after a few years of Haskell programming, I am still not sure how to indent if-then-else.

what I was alluding to in my footnote...

I think there's really only one way when it needs to occupy more than one line: if c then t else f Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

Confusingly,

if c then t else f

Also works, although no-one really knows why.

Actually, it doesn't work inside a `do' layout, Stefan

Brian Hulley wrote:

Anyway, how about changing the syntax to:

"if" exp "{" "then" exp ";" "else" exp "}"

Layout has to be triggered by distinguished keywords before the brace. -- Andreas Rossberg, rossberg@ps.uni-sb.de

Thanks for the answer. (And doubly thanks for giving the answer I hoped for!) I propose that ifThenElse and thenElseIf be added to the Prelude for Haskell'. While these names are a bit long, I think we want both functions and these names make the behaviors clear (to me, at least). Comments? -m Paul Hudak writes:

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

G'day all. Quoting Benjamin Franksen :

For what it's worth, I have been asking myself the same question several times. If/then/else syntax could be replaced by a regular (lazy) function without any noticeable loss.

I believe that if-then-else cannot be replaced by a regular function for the same reason that regular function application and ($) are not identical. The loss may not be noticeable, but it's still a loss. It could be replaced by a case-switch-on-Bool, though.

IMHO, the next standardized version of Haskell, however named, should abandon the special if/then/else syntax so we'll have at least /one/ item where the language becomes smaller and simpler.

The de facto Haskell philosophy, if you read the history paper, is to have a small core language with a lot of syntactic sugar. The syntactic sugar is specified by translation to the core language. The small core ensures that Haskell remains simple. If you discount changes in the type system, the Haskell core language is as simple now as it was in 1989.

Remember: Perfection is reached not when there is nothing more to add, but rather when there is nothing more to take away.

Perfection is asymptotically approached when arbitrary restrictions are removed and special cases are dumped in favour of general, theoretically sound, principles. Perfection will never be reached in a practical programming language, but it may be asymptotically approached. Cheers, Andrew Bromage