I hope you're not tired of receiving other people'...

2007-04-08T14:36:00.000-07:00

I hope you're not tired of receiving other people's implementations on here... I am learning myself and thought a reimplementation of your program here would be fun. And it was! So I hope my version elucidates some things, with a little commentary.

It took a long time for me to get comfortable enough with monads that I could do IO the way I do in this program. I laud your implementation and I hope you'll keep on keepin' on. Haskell is hard to learn and the type system often doesn't help. I started including annotations because everyone else does and it actually seems to help find bugs and improve the design.

> module GolfScore where
> import Data.List -- for the sort function

One thing a friend told me is that you are going to want functions that take a simple type and return stuff inside a monad, rather than monkeying around with monad -> monad typed functions. Actually in general do it as purely as possible; if you have to return in a monad that's fine but if you can return a pure value instead, do that; there are ways of lifting that function into the monad when you have to. Because the monad operations are all intended to help you glue functions with that kind of type together. Which is what I've got in this code:

> getName :: IO String
> getName = putStr "Enter name: " >> getLine
>
> getScore :: IO Integer
> getScore = putStr "Enter score: " >> getLine >>= return . read

Then I combined these primitives to make one which handles getting a person's name and score. I decided it would be more convenient to carry them around in a 2-tuple rather than two lists, because it makes the relationship concrete.

> getNameAndScore :: Int -> IO (String, Integer)
> getNameAndScore holes = do
> name <- getName
> scores <- sequence $ replicate holes getScore
> return (name, sum scores)

Sequence and replicate form the basis of my iteration in this program. It lets me avoid any explicit looping, because we're really just doing the same things over again and collecting the result. I recommend spending time reading the prelude, it helped me quite a bit to see what's there and built-in already. Anyhow, sequence and sequence_ are handy because they let you take a list of monadic actions and convert them into a list of results. mapM is similar, essentially applying a monad action to a list and collecting the result.

Here are my output functions:

> showResult :: String -> Integer -> IO ()
> showResult name score = putStrLn $ name ++ " got a score of " ++ (show score)
>
> showResults :: [(String, Integer)] -> IO ()
> showResults = mapM_ (uncurry showResult)

So showResults is clearly intended to take the output of getNameAndScore. showResult probably could have been coded to take a 2-tuple but I like using uncurry and I don't like writing functions that take tuples unless I really have to. Pet peeve I guess. And there's the aforementioned mapM. The underscore variants tend to throw away their results, which is fine here, because showResult produces IO (), and mapM would give me back a list of [IO (), IO ()...]. Not something I care to keep around.

And here is your essential function. I did add one thing, it sorts by score, showing the winner at the top. :)

> run :: Int -> Int -> IO ()
> run count holes = do
> namesAndScores <- sequence $ replicate count (getNameAndScore holes)
> let sorted = sortBy (\l r -> compare (snd l) (snd r)) namesAndScores
> showResults sorted

The sequence $ replicate construct there is the same as the one above, creating a list of monad actions and then evaluating them. I had a tendency when I was starting to try and write the second line as "sorted <- sortBy ..." but that of course doesn't work because it is a pure function result. The let solves this problem. sortBy takes a function and a list; my function just pushes the compare into the second item of the tuple and sorts based on that, which happens to be the score. Then I show the results.

The easiest step to improve your code is using lib...

2006-12-20T02:45:00.000-08:00

The easiest step to improve your code is using library functions for recursion patterns.

showResults = zipWithM showResult
where showResult x y = putStrLn (x ++ " got a score of " ++ show y)

getScores count =
replicateM count (putStr "Enter score:" >> getLine)

The scoring in run can be simplified a little bit.

foldr ((+) . read) 0 scores ==
foldr (+) 0 (map read scores) ==
sum (map read scores)

run can be done with replicateM, if it accumulates results as a list of pairs rather than a pair of lists.

run count holes = do
results <- replicateM count (do
putStr "Enter name:"
name <-getLine
scores <- getScores holes
return (name, scores))
showResults (unzip results)

For good code, I would split this (trivially) into a game reading and a game printing function.

For maximum brevity, inline the helpers and create the output IO actions while reading in the game.

run count holes =
sequence_ =<< replicateM count (do
name <- putStr "Enter name:" >> getLine
scores <- replicateM holes (putStr "Enter Score:" >> getLine)
return $ putStrLn $ name ++ " got a score of "++show (sum (map read scores)))

The 'read' function is useful for translating a St...

2006-12-19T19:01:00.000-08:00

The 'read' function is useful for translating a String to an Integer (or any other data type in the Read class).

> read "36" :: Integer
36

> 7 + (read "19")
26

> read "[1,2,3]" :: [Integer]
[1,2,3]

Comments on Programming Experiments: Haskell Golf Scores

I hope you're not tired of receiving other people'...

The easiest step to improve your code is using lib...

The 'read' function is useful for translating a St...