[Haskell-cafe] Re: [darcs-users] Iteratees, streams, and mmap

Heinrich Apfelmus apfelmus at quantentunnel.de
Sun Dec 13 05:53:57 EST 2009


Jason Dagit wrote:
> Johann Höchtl wrote:
>>
>> As a beginner to Haskell, I am only 1/3 through RWH, those lines scare
>> me in a sense to question my effort. I simply can not distinguish if
>> this discussion is somewhat pathological in a sense that every access
>> to the outside world imposes dangers and an additional exception
>> handler here and there and an additional if-statement to handle error
>> return codes will suffice.
>>
> 
> We're not talking about exception handling :)  And yes, Heinrich is talking
> about pathological cases.
> 
> 
>> Or lazy evaluation, IO monads and the whole story behind
>> unsafePerformIO was an additional layer of self-deception and
>> unpredictable effects from the outside world and lazy evaluation can
>> NEVER be satisfactory handled.
>>
> 
> We're not talking about unsafePerformIO either.
> 
> The discussion at hand is much simpler.  Given a large stream of data, how
> should you style your code so that it's easy to reason about the space
> usage?  This is an important question in every programming language I've
> ever used.  Also, IO need not enter the discussion except that in darcs the
> streams of data come from the disk.  I think moving the discussion to
> haskell-cafe was a mistake.  I said what I said in a very specific context
> (that of the darcs developers mailing list), which is likely no longer
> clear.
> 
> Sorry for any distress this has caused you.

Ah, I didn't mean to cause distress to anyone by cross-posting to the
café. I just thought that a discussion "Is there a style of writing
Haskell that makes it easy to ensure bounded space usage?" could be of
general interest.



Johann, don't worry, lazy evaluation is awesome. :) See for example

   http://apfelmus.nfshost.com/quicksearch.html


It's just that laziness not a free lunch; predicting memory ("space")
usage does become more difficult. Which is not really surprising since
deferring the evaluation of thunks until they are demanded also means
that they will store different expressions of possibly different sizes
before and after they are demanded.

Classic examples are

   ones = 1:ones

taking O(1) memory instead of an infinite amount and

   foldl (+) 0 [1..n]

taking O(n) memory as opposed to

   foldl' (+) 0 [1..n]

which only takes O(1) memory.



Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com



More information about the Haskell-Cafe mailing list