Personal tools

Common Misunderstandings

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
m (Clarified "polymorphically" in the sentence fragment "but to code it so that each tower could be named polymorphically.")
m (Added a comma after "polymorphically " in the sentence fragment "but to code it so that each tower could be named polymorphically using.")
Line 62: Line 62:
 
Some beginners make the mistake of mistaking a single-element list pattern (such as <hask>[x]</hask>) for a pattern that iterates over every element in the list.
 
Some beginners make the mistake of mistaking a single-element list pattern (such as <hask>[x]</hask>) for a pattern that iterates over every element in the list.
   
One example that recently (in April, 2008) appeared on the Haskell-Cafe mailing list (see the reply post [http://www.haskell.org/pipermail/haskell-cafe/2008-April/041701.html Re: Embedding newlines into a string?]) was the following. Here, one coder attempted to write a function <hask>hanoi</hask> to solve the Towers of Hanoi problem, but to code it so that each tower could be named polymorphically using, for example, either Chars or Ints. The problematic code segment was the following:
+
One example that recently (in April, 2008) appeared on the Haskell-Cafe mailing list (see the reply post [http://www.haskell.org/pipermail/haskell-cafe/2008-April/041701.html Re: Embedding newlines into a string?]) was the following. Here, one coder attempted to write a function <hask>hanoi</hask> to solve the Towers of Hanoi problem, but to code it so that each tower could be named polymorphically, using, for example, either Chars or Ints. The problematic code segment was the following:
   
 
<haskell>
 
<haskell>

Revision as of 05:21, 17 April 2008

Contents

1 Common Mistakes and Incorrect Beliefs By Haskell Beginners

People going from zero to Haskell are likely gain a misunderstanding or miss a point that isn't stressed enough. Here are some mistakes that have been observed from multiple sources.

1.1 Indentation

Perhaps the first trip-up - you might understand that indentation defines where a code block starts and the lack of an equal amount of indentation indicates the previous code block ended. What some miss is that
then
and
else
must be indented deeper than the
if
statement:
if boolean
    then expr1
    else expr2

Or they can be on the same line as the if:

if boolean then expr1 else expr2

1.2 If / Then / Else

if-then statements must always include an 'else' portion. It might be best not to think of if-then-else as flow control, as in most imperative languages, but think of it as construction of a value using a well formed expression.

x = b ? y : z;

The above is valid, though not common, C code. It states that if b is true then x = y otherwise x = z. Notice how this makes no sense without z. Similarly, in Haskell an
if
/
then
makes no sense without an
else
.
let x = if b then y   -- compare to x = b ? y
What is x when b is false? One should also recognize that the types returned by the
then
and
else
branches must match due to Haskells strong and static type system. When
if
is used for sequencing IO it is not uncommon to see an
else
that returns a null value:
main = do
    startNetwork <- askUser "Network? "
    if startNetwork
        then do iface <- initNetworkInterface
                handlePackets iface
        else return ()
Such uses can be more succinct if they use the
when
keyword:
main = do
    startNetwork <- askUser "Network? "
    when startNetwork (do
        iface <- initNetworkInterface
        handlePackets iface )


1.3 do Notation

If the do notation page ever exists I'll advice you to check it out. Until then, understand that a missing
do
from the top of a function or code block can result in your compiler giving an error message citing a much later line number. Also, any new blocks (ex: from an
if
or
case
) must have their own
do
, even if the higher level code block already had one.

Sorry this isn't the full picture - for an inverse point of view see do notation considered harmful.

1.4 Iterating Over a List

Some beginners make the mistake of mistaking a single-element list pattern (such as
[x]
) for a pattern that iterates over every element in the list. One example that recently (in April, 2008) appeared on the Haskell-Cafe mailing list (see the reply post Re: Embedding newlines into a string?) was the following. Here, one coder attempted to write a function
hanoi
to solve the Towers of Hanoi problem, but to code it so that each tower could be named polymorphically, using, for example, either Chars or Ints. The problematic code segment was the following:
hanoi_shower :: Show a => [(a, a)] -> String
hanoi_shower [(a, b)] = "Move " ++ show a ++ " to " ++ show b ++ "."

in the following program:

hanoi :: a -> a -> a -> Int -> [(a, a)]
hanoi a b c n = hanoi_helper a b c n
 
hanoi_helper :: a -> a -> a -> Int -> [(a, a)]
hanoi_helper source using dest n
    | n == 1 = [(source, dest)]
    | otherwise = hanoi_helper source dest using (n-1)
                  ++ hanoi_helper source using dest 1
                         ++ hanoi_helper using source dest (n-1)
 
hanoi_shower :: Show a => [(a, a)] -> String
hanoi_shower [(a, b)] = "Move " ++ show a ++ " to " ++ show b ++ "."

The coder tried to run the code in WinHugs as follows:

Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2))

However, this was the result:

Program error: pattern match failure: hanoi_shower
[('a','b'),('a','c')] ++ ([] ++ hanoi_helper 'b' 'a' 'c' (2 - 1))
The problem was that the parameter
[(a, b)]
to
hanoi_shower
only matched the first element of the list, but didn't iterate over the list as intended.

Here is a corrected version of the code above:

hanoi_shower :: Show a => [(a, a)] -> String
hanoi_shower moves = unlines ["Move " ++ show a ++ " to "++ show b ++ "." | (a, b) <- moves]
Here,
moves
is pattern-matched to type
[(a, a)]
(a list of pairs). The problem is how to iterate over the elements (pairs) of the list while separating the first
a
of each pair from the second
a
. The solution above uses list comprehension: the generator
(a, b) <- moves
feeds each pair in turn to the left-hand expression
(a, b)
, and this pair is mapped to the left expression,
"Move " ++ show a ++ " to "++ show b ++ "."
, building a new list of sentences representing moves. Then, the function
unlines
breaks this list into a sequence of lines.

Here is the result of executing the above code in WinHugs:

Main> putStr (hanoi_shower (hanoi 'a' 'b' 'c' 2))
Move 'a' to 'b'.
Move 'a' to 'c'.
Move 'b' to 'c'.

Main> putStr (hanoi_shower (hanoi 1 2 3 2))
Move 1 to 2.
Move 1 to 3.
Move 2 to 3.
Notice that since
a
and
b
in
(a, b)
are polymorphic types, they can range over both
Chars
and
Ints
. Another way of writing
hanoi_shower
, using
map
, is as follows:
hanoi_shower :: Show a => [(a, a)] -> String
hanoi_shower moves = unlines (map move moves)
                     where move (a, b) = "Move " ++ show a ++ " to "++ show b ++ "."
Here,
move
is mapped over
moves
, and each pair
(a, b)
of
moves
is pattern-matched against
"Move " ++ show a ++ " to "++ show b ++ "."

Another way to map over a list is to use recursion, although this method is considered non-idiomatic Haskell (Haskellers generally prefer using higher-order functions over recursion when possible):

hanoi :: a -> a -> a -> Int -> [(a, a)]
hanoi source using dest n
    | n == 0 = []
    | n == 1 = [(source, dest)]
    | otherwise = hanoi source dest using (n-1) 
                  ++ hanoi source using dest 1
                         ++ hanoi using source dest (n-1)
 
hanoi_shower :: Show a => [(a, a)] -> String
hanoi_shower [] = ""
hanoi_shower ((a, b):moves) = unlines ["Move " ++ show a ++ " to "++ show b ++ "."] ++ hanoi_shower moves
Here, in
hanoi_shower
, the base case is simply an empty list
[]
. At each recursive step, a list of type
[(a, a)]
(a list of pairs) is mapped against the parameter
(a, b):moves
of
hanoi_shower
. This separates the head of the list
(a, b)
from the tail of the list
moves
, which then is further matched against
((a, b):moves)
on the next recursive call.

There are other ways of iterating over lists as well. One advantage of Haskell is that there are often many ways of performing the same action, including iterating over lists.