[Haskell-cafe] Haskell & monads for newbies

Paul Moore p.f.moore at gmail.com
Sun Jul 15 15:03:39 EDT 2007

On 15/07/07, Andrew Coppin <andrewcoppin at btinternet.com> wrote:
> I guess because in most normal programming languages you can do I/O
> anywhere you damn like, it doesn't occur to most programmers that it's
> possible to make a seperation. (Most seem to realise that, e.g., mixing
> business logic with GUI code is a Bad Thing though...)

Hmm, I would speculate (I have no hard data, in other words...) that
it's more the case that in imperative languages, you do I/O throughout
the program, because that defers the I/O (which is slow) to the last
possible moment, and it allows you to reuse memory buffers.

People's intuition about performance and memory usage says that
delaying I/O is good, and "separating" I/O and logic (which is taken
to mean slurping data in all at once, and then processing it) is
memory intensive and risks doing unnecessary I/O.

Haskell handles this with laziness. The canonical example is counting
characters in a file, where you just grab the whole file, and use
length. An imperative programmer's intuition says that this wastes
huge amounts of memory compared to reading character by character and
incrementing a count. Lazy I/O means that no more than 1 character
needs to be in RAM at any one time, without the programmer need to do
the bookkeeping.

If lazy I/O was publicised in this way, as separation of concerns (I/O
and processing) with the compiler and language handling the work of
minimising memory use and avoiding unnecessary I/O, then maybe the
message might get through better. However, the only article I've ever
seen taking this approach (http://blogs.nubgames.com/code/?p=22)
didn't seem to get a good reception in the Haskell community, sparking
comments that hGetContents and similar functions had a number of
issues which made them "bad practice". The result was to leave me with
a feeling that separating I/O and processing in Haskell really was
hard, but I never quite understood why...

So I guess that leaves me with the question: is separating I/O and
processing really the right thing to do (in terms of memory usage and
performance) in Haskell, and if so, why isn't it advertised more? (And
for extra credit, please explain why the article I quoted above didn't
make more of an impact in the Haskell community... :-))


More information about the Haskell-Cafe mailing list