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

[Robert Dockins]

On Jul 28, 2006, at 12:32 AM, Mike Gunter wrote:

> 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?

If we're planning on adding some boolean stuff to the Prelude, I'd  
like to suggest we add:

bool :: a -> a -> Bool -> a
bool f t b = case b of { False -> f; True -> t }

Why?  Because we already have the "maybe" and "either" functions in  
the prelude which are the catamorphisms on their respective types.   
While we're at it, we might as well throw in (ordering :: a -> a -> a  
-> Ordering -> a) as well.  That would mean all the algebraic types  
defined in the Prelude also have their catamorphisms defined (eh,  
except for n-tuples where n>2, sigh... I guess one could add  
uncurry3, uncurry4, etc....).


On an almost completely unrelated note, I've sometimes thought that  
it would be nice to be able to have the compiler auto-magicly  
generate catamorphisms for datatypes upon request.  No, I haven't  
thought out the details.


> -m
>
>
> Paul Hudak <paul.hudak at yale.edu> 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


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG