- 1 Replace syntactic sugar by a function
- 2 Advocacy
- 3 Objections
Replace syntactic sugar by a function
For processing conditions,
if-then-else syntax was defined in Haskell98.
However it could be simply replaced by the function
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
over the syntax
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' 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 function.
For example, the Hoogle query
[Bool] -> [a] -> [a] -> [a]
Each of the following functions could be defined in terms of
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 language.
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 applies.
select :: a -> [(Bool, a)] -> a select = foldr (uncurry if')
Why add this function to Prelude?
Actually people could define
if' in each module,
where they need it,
or import it from a
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
Is If-Then-Else so important?
in today's Haskell programs
isn't a good measure for the importance a
- frequently guards are used instead of
- 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?
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
if-then-else simplifies every language tool,
say compiler, text editor, analyzer and so on.
If we arrive at Haskell two some day, (http://haskell.org/hawiki/HaskellTwo)
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
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