Purity

However, if you just want to write the results of a calculation to a file, it’s usually possible to ignore these issues, by replacing putStr with writeFile. One twist you’ll probably need is to convert the result of the calculation into a string first. Happily show does a passable job of that most of the time (and ghci uses it implicitly):

Source files

So far, all of these examples are just typed at the ghci prompt. In practice, for more complicated calculations, or those you want to keep, it’s helpful to save things in a Haskell file which you can then load into ghci.

There’s nothing very sophisticated or elegant about it, but equally the source code is almost exactly what I’d write on paper were I to do it by hand.

However, unlike the paper version, it would be easy to extend this if I wasn’t sure of some of the values and wanted to calculate all the possible coordinates. If I felt particularly keen I could even write them to a file, perhaps in a format that e.g. Google Earth could understand.

Weaknesses

Text

Although it’s not always true, I still find Perl a better tool for quickly munging text. Perhaps it’s familiarity, or perhaps the seemless integration of regexps into the language remove just that bit of friction.

External data

One of the consequences of Haskell’s immutable data and purity is that it can be messy to work with e.g. a dictionary stored in a file. The contents of that file might change, so deep in the bowels of a library you can’t simply open it and read the contents, without jumping through a hoop or two.

For small–medium sized data sets, simply embedding the data in a Haskell source file seems a reasonable hack. Typically I’d write some trivial program to create that source file, which could then be included like any other library.