Robert Dockins robdockins at fastmail.fm
Fri Jul 28 10:07:24 EDT 2006

```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).
>

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

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

```