[ddfisher]

Because Haskell is evaluated lazily, two maps doesn't imply two iterations over the data. In this case, I would expect only one pass through the data for both of the maps. Out of curiosity, I did a quick criterion benchmark for both functions. Here's the result on a list of 100 elements:

  benchmarking spark_mggcl
  mean: 49.29483 us, lb 48.77776 us, ub 50.25594 us, ci 0.950
  std dev: 3.495423 us, lb 2.140951 us, ub 6.373469 us, ci 0.950

  benchmarking spark_ocharles
  mean: 60.12347 us, lb 58.95586 us, ub 61.48084 us, ci 0.950
  std dev: 6.434853 us, lb 5.529613 us, ub 7.824865 us, ci 0.950 

The simpler version appears to be faster.

(As an aside, is there something in particular you dislike about do syntax? I find that it often makes things more readable, though slightly more verbose.)

[ocharles]

I am aware of that, as I said this was more a mental exercise. normalizeMap is harder to understand, but it was interesting to write - it wasn't meant to be a stab at your code or claim it's better :)

In terms of do syntax, I try and avoid that because I find it detracts from the overall flow of data. With: "putStrLn . spark . map read =<< getArgs" I find it easy to see that main doesn't do much other than transform the users input. maybe a personal preference thing though...