Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why does Haskell have a built-in if/then/else, which is dependent on the Bool type, instead of having a simple library function? Such as

if :: Bool -> a -> a -> a
if True  x _ = x
if False _ y = y
share|improve this question
3  
I would guess they explicitly wanted the if/then/else syntax which they can't get without mixfix functions like they have in agda. The function you refer to is structured as a ternary, which you could implement yourself though I presume they gave us if/then/else sugar (it's likely just sugar over a case) just because they could and it's harmless.. But I have nothing to back me up here, which is why I'm writing this in a comment. –  Jimmy Hoffa Apr 22 '13 at 14:12
1  
The signature should be if :: Bool -> a -> a -> a –  Nikita Volkov Apr 24 '13 at 14:10
1  
@NikitaVolkov Thanks, I missed the last -> a. Corrected. –  Petr Pudlák Apr 24 '13 at 16:42
9  
This might be obvious to most of the readers, but I would like to point out that having îf/then/else as a function would not be a good solution in an eager language (e.g. scheme or sml) while it is reasonable in a lazy language like Haskell. –  Giorgio Apr 24 '13 at 17:00
add comment

2 Answers

up vote 17 down vote accepted

It's purely for the nice sugar of the if, then, and else keywords; in fact, GHC (with the RebindableSyntax extension enabled) will desugar the syntax by simply calling whatever ifThenElse function is in scope.

share|improve this answer
add comment

It doesn't matter much ... to me it looks like if/then/else is not used very often nowadays. I find myself writing pattern guards instad of if .. then .. else.

From a syntactic point of view, though, it is nice to have

if expr1 then expr2 else expr3

So you can write

if foo a then bar b else baz c

instead of

if (foo a) (bar b) (baz c)

which looks a bit too LISPish to me.

For semantic analysis and code generation, it is nice to have this construct, which can easily be compiled to efficient machine code. Note that the code can skip the part that makes the thunk for the branch that is not reached, as opposed to a function call, where the (unevaluated) parameters must all be passed. But it also costs time (and memory, that must be reclaimed later) to create the thunk. To make good on this, one would have to inline the if function everywhere.

share|improve this answer
1  
I don't think the inlining is an actual issue. My understanding is that GHC is already exceptionally good at inlining small functions, because it's just such a common pattern in Haskell. –  Tikhon Jelvis Apr 24 '13 at 22:50
1  
@TikhonJelvis Sure, but with if/then/else you don't need a special function that must always get inlined. You don't even need an inlining pass and still you can generate decent code. Not all the world is GHC. –  Ingo Apr 25 '13 at 16:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.