data Doc = Empty
         | Char Char
         | Text String
         | Line
         | Concat Doc Doc
         | Union Doc Doc
         deriving (Show, Eq)

There’s no distinction between the value constructor and the components of the type. This is especially critical when the constructor and the components have the same name as in the Char constructor above. It also doesn’t help that they have the same naming convention (mixed camel case, initial uppercase letter).

A Java class with multiple factory methods or multiple constructors would be much more verbose, but much more readable. Humans need redundancy, even if it’s logically superfluous.

I suspect a language that retained Haskell’s semantics, but completely replaced the syntax with something more usable, legible, and familiar would have a much greater chance of success.

myUnlines :: [String] -> String
myUnlines xs = foldr (addLine) "" xs
    where addLine c acc = acc ++ c ++ "\n"

It’s pretty much straight down the path of exactly what folds are meant for, though the inferred types still managed to surprise me, and my initial implementation was about twice this size.

myWords :: String -> [String]
myWords s = reverse (foldr step [] (trim s))

step :: Char -> [String] -> [String]
step c [] = [c:[]]
step c acc
    | (isSpace c) = acc ++ [""]
    | otherwise = (take ((length acc) - 1) acc) ++ [c:(last acc)]

isSpace :: Char -> Bool
isSpace ' '  = True
isSpace '\n' = True
isSpace '\r' = True
isSpace '\t' = True
isSpace _    = False

lstrip :: String -> String
lstrip [] = ""
lstrip (x:xs)
  | (isSpace x) = lstrip xs
  | otherwise = x:xs

rstrip :: String -> String
rstrip s = reverse (lstrip (reverse s))

trim :: String -> String
trim = lstrip . rstrip

Moral of this exercise: you can only pass a list to ++. You can’t use ++ to append a Char to a String. You have to append [c] instead.

There’s probably an isSpace function in the standard library somewhere I could be using instead. (Found it. It’s Char.isSpace)

The trim function feels unnecessary. A more clever implementation of the fold might avoid it.

And that reverse is really yucky. I should be able to rewrite the fold so the values come out in the right order.

1. The infinite list would have to be the accumulator.
2. A fold (foldr or foldl) operation steps over (processes) each element of the finite input list exactly once.
3. Each step can insert only a finite number of elements into the accumulator list.
4. Thus the final accumulated list must be finite.

Of course, Murphy’s Law guarantees that someone is now going to post a cycle implementation with pure folds in the comments. If there’s a mistake in this proof, it’s in step 3. But it really feels to me like a fold alone won’t do the trick. You have to use recursion of some sort here. Maybe a fold of folds? What if the step function is itself a fold?

I’m beginning to hate type inference. Yes the compiler can figure out the types, but the human (i.e. me) often can’t without running the compiler. Redundancy and verbosity are not bugs. They are features. Human language (e.g. English) is verbose and redundant for good reason. Redundancy helps humans understand.

The source code is not just for the compiler. Otherwise we’d write in machine language. User interface factors need to be considered in the design of programming languages.

Write your own definition of the standard takeWhile function, first using explicit recursion, and then foldr.

myTakeWhile :: (a -> Bool) -> [a] -> [a]
myTakeWhile _ [] = []
myTakeWhile f (x:xs) = if (f x)
                       then x : (myTakeWhile f xs)
                       else []

fMyTakeWhile :: (a -> Bool) -> [a] -> [a]
fMyTakeWhile f (xs) = foldr step [] xs
     where step x ys | f x = x : ys
                     | otherwise = [] 

The asInt_fold function uses error, so its callers cannot handle errors. Rewrite it to fix this problem.

-- file: ch04/IntParse.hs
import Data.Char (digitToInt) 

asInt :: String -> Int
asInt ('-':xs) = -1 * asInt xs
asInt xs = foldl step 0 xs
  where step acc x = acc * 10 + safeDigitToInt x

safeDigitToInt :: Char -> Int
safeDigitToInt x =  if x >= '0' && x <= '9'
                      then digitToInt x
                      else error "Non-digit"

asInt_either :: String -> Ei
asInt_either xs = if onlyHasDigits xs
                  then Main.Right (asInt xs)
                  else Main.Left ("non-digit '" ++ ((firstNonDigit xs) : "'"))

onlyHasDigits :: String -> Bool
onlyHasDigits [] = True
onlyHasDigits (x:xs) = if x >= '0' && x <= '9'
                      then onlyHasDigits xs
                      else False

firstNonDigit :: String -> Char
firstNonDigit [] = '\0'
firstNonDigit (x:xs) = if x <= '0' || x >= '9'
                      then x
                      else firstNonDigit xs

data Ei = Right Int
          | Left String
        deriving (Show)

Doubtless this could be much mproved by someone who knows what they’re doing.

Write a program that transposes the text in a file. For instance, it should convert “hello\nworld\n” to “hw\neo\nlr\nll\nod\n”.

cc :: String -> String -> String
cc x y = x ++ y ++ "\n"

transposeSingle :: String -> String
transposeSingle [] = []
transposeSingle (x:xs) = x : '\n' : (transposeSingle xs)

-- the accumulator string and the next line
transposeDouble :: String -> String -> String
transposeDouble x y = concat (zipWith (cc) (lines x) (lines (transposeSingle y)))

transposeEven :: [String] -> String
transposeEven [] = []
transposeEven [x] = (transposeSingle x)
transposeEven (x:xs) = foldl (transposeDouble) (transposeSingle x) xs

transpose :: String -> String
transpose s = transposeEven (pad (maxLength s) (lines s))

-- pad each line with spaces to maximum length
maxLength :: String -> Int
maxLength s = maximum (map length (lines s))

pad :: Int -> [String] -> [String]
pad _ [] = []
pad n (x:xs) = (padOneLine (n - (length x)) x) : (pad n xs)

padOneLine :: Int -> String -> String
padOneLine n s = if n > 0
                 then padOneLine (n-1) (s ++ ".")
                 else s

The exercise wasn’t clear on what you should do when not all lines were the same size, so I padded them out with periods.

This took way longer to implement than it should have, and I had to use several functions from later parts of the book. I certainly could have implemented this faster in Java or, to pick a language I haven’t been using day in and day out for 14 years, Python. Doubtless an experienced Haskell programmer could come up with a simpler implementation.

On the positive side, the interactive ghci shell was a big help in debugging this, and by their very nature Haskell’s pure functions are very amenable to testing and debugging in isolation. However, I still have to learn how to do real test driven development in Haskell. (One thing I proved to myself a couple of jobs ago was that TDD matters a lot more than what language you code in. I figured this out after I realized I could write correct Python code faster than the professional Python programmers we had hired because I was using TDD and they weren’t. This despite the fact that I knew next to no Python and they had years of experience in the language. Of course, an experienced Python programmer who did use test-driven development could still wipe the floor with me. )

The : operator prepends an item to the beginning of a list. It can only be used to insert an item at the beginning of a list. It cannot be used to append an item to the end of a list. Thus x:xs is correct but xs:x is a syntax error. (Haskell’s design seems stuck with assumptions going all the way back to Lisp and 1950s era processors including that the singly linked list is a good implementation for the list abstract data type. This has other consequences. For instance, length is an O(n) operation. And now that I look for it, insert into the middle of the list also seems to be missing.)

Lists are concatenated with the ++ operator, not :.

So, to sum up:

• Use : to insert an item at the beginning of a list.
• Use ++ to join two lists together.
• To append an item to a list, insert the item into an empty list, and then concatenate the two lists together.
• More generally, to insert an item into a list at any position other than the first:
  1. Split the list into two sublists at the insertion point with splitAt.
  2. Use : to prepend the new item to the second list.
  3. Concatenate the two lists back together with ++

Am I missing something obvious here?

--->  Cleaning perl5.8
--->  Fetching ghc
--->  Attempting to fetch ghc-6.10.1-src.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/
--->  Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/
--->  Attempting to fetch ghc-6.8.2-darwin-i386-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/
--->  Verifying checksum(s) for ghc
--->  Extracting ghc
--->  Applying patches to ghc
--->  Configuring ghc
--->  Building ghc

Certainly it was long enough to answer a bunch of e-mails, and edit an article. Is this the point where it actually compiles the compiler? Is ghc self-hosting? That is, is ghc written in ghc? That may be what the bootstrap bit is about. Yep, looks like it is.

I do remember 2 hour gcc compiles, but that was 15 years ago on much slower hardware. How long does it take to compile a compiler nowadays?