Indentation of If-Then-Else

Henning Thielemann haskell at
Tue Oct 24 05:40:09 EDT 2006

On Mon, 23 Oct 2006, Philippa Cowderoy wrote:

> On Mon, 23 Oct 2006, Cale Gibbard wrote:
> > Of course I disagree with this course for all the reasons I stated
> > above. The whole point of having high level programming languages is
> > so that you can put more work into the tools so that the end user
> > doesn't have to work as hard. One shouldn't ask "What's easiest to
> > parse?" but "What's easiest to read and write?".
> > 
> A good many tools can, of course, get by on a reversible desugaring. It 
> seems to me that this'd be a sensible candidate for a library.

I have tried to sum up my points about if-then-else syntax and answer some
question that were arised by others. Even if it doesn't influence the
decision about the optional semicolon, it will well become of interest
once HaskellTwo design procedure starts.


Replace syntactic sugar by a function 

For processing conditions, the if-then-else syntax was defined in 
Haskell98. However it could be simply replaced by the function if' with 

if' :: Bool -> a -> a -> a
if' True  x _ = x
if' False _ y = y

Unfortunately there is no such function in the Prelude. 



The advantages of the function if' over the syntax if-then-else are the 
same like for all such alternatives. So let me repeat two important 
non-syntactic strengths of Haskell: 

types: classification, documentation 
higher order functions: combinators 

If if' would be a regular function, each language tool can process it 
without hassle. Haddock can generate documentation for it, a text editor 
can make suggestions for values to insert, Hoogle can retrieve that 

For example, the Hoogle query 

[Bool] -> [a] -> [a] -> [a]

may return 

zipWith3 if'


 Use cases 

Each of the following functions could be defined in terms of if'. 
Actually, they do not even need to be in Prelude because they can be 
constructed so easily. 

That function is harder to explain in English, than by its implementation. 

zipIf :: [Bool] -> [a] -> [a] -> [a]
zipIf = zipWith3 if'

Select a member of a pair. This resembles the cond?x:y operation of the C 

infixr 1 ?:
(?:) :: Bool -> (a,a) -> a
(?:) = uncurry . if'

>From a list of expressions choose the one, whose condition is true. The 
first parameter is the default value. It is returned if no condition 

select :: a -> [(Bool, a)] -> a
select = foldr (uncurry if')

See Case. 


 Why add this function to Prelude? 

Actually people could define if' in each module, where they need it, or 
import it from a Utility module, that must be provided in each project. 
Both solutions are tedious and contradict to modularization and software 
re-usage. The central question is, whether if' is an idiom, that is so 
general that it should be in the Prelude, or not. I think it is, otherwise 
it wouldn't have get a special syntax. 

 If-Then-Else vs. guards 

Actually if-then-else isn't used that often today. Most programmers gave 
it up in favor of guards. This practice has its own drawbacks, see 
Syntactic sugar/Cons and Things to avoid. 


 Is If-Then-Else so important? 

Counting if-then-else or if' in today's Haskell programs isn't a good 
measure for the importance a if' function, because 

frequently guards are used instead of if-then-else 
there is no standard function, and this let people stick to work-arounds. 

 What is so bad about the if-then-else sugar? 

Since syntactic sugar introduces its own syntactic rules, it is hard to 
predict how it interferes with other syntactic constructs. This special 
syntax for instance led to conflicts with do notation. A syntactic 
extension to solve this problem is proposed for Haskell'. It is not known 
what conflicts this extension might cause in future. 


 Why breaking lots of old and unmaintained code? 

Haskell without if-then-else syntax makes Haskell more logical and 
consistent. There is no longer confusion to beginners like: "What is so 
special about if-then-else, that it needs a separate syntax? I though it 
could be simply replaced by a function. Maybe there is some subtlety that 
I'm not able to see right now." There is no longer confusion with the 
interference of if-then-else syntax with do notation. Removing 
if-then-else simplifies every language tool, say compiler, text editor, 
analyzer and so on. 

If we arrive at Haskell two some day, 
( it will certainly be incompatible 
to former Haskell versions. This does not mean, that old code must be 
thrown away. There should be one tool, that converts Haskell 98 and 
Haskell' to Haskell-2. Having one tool for this purpose is better than 
blowing all language tools with legacy code. Syntactic replacements like 
if-then-else syntax to if' function should be especially simple. 



Light proposal, compatible with Haskell 98: Add if' to the Prelude, maybe 
with a different name. 
Full proposal, incompatible with Haskell 98 and Haskell': Additionally 
remove if-then-else syntax 


 See also 

Syntactic sugar/Cons 
Things to avoid/Discussion 



Haskell is not intended to be a minimalistic language, but to be one, that 
is easy to read. if-then-else resembles a phrase from English language. It 
shows clearly which expression is returned on a fulfilled condition, and 
which one is returned for an unsatisfied condition. It is thus easier to 
read. The special syntax saves parentheses around its arguments. If 
properly indented, like 

if a
  then b
  else c


if a
  then b else c

then there is no conflict with the do-notation. 

More information about the Haskell-prime mailing list