[Haskell-cafe] Either Monad and Laziness

Eric Velten de Melo ericvmelo at gmail.com
Wed Sep 12 17:04:31 CEST 2012

On 12 September 2012 11:46, Eric Velten de Melo <ericvmelo at gmail.com> wrote:
> Thanks for all the tips! The iteratees seem worth checking out. I'll
> see what I can do and will report back if I come up with something.
> Eric
> On 12 September 2012 03:03,  <oleg at okmij.org> wrote:
>>> I am currently trying to rewrite the Graphics.Pgm library from hackage
>>> to parse the PGM to a lazy array.
>> Laziness and IO really do not mix.
>>> The problem is that even using a lazy array structure, because the
>>> parser returns an Either structure it is only possible to know if the
>>> parser was successful or not after the whole file is read,
>> That is one of the problems. Unexpected memory blowups could be
>> another problem. The drawbacks of lazy IO are well documented by now.
>>> The behaviour I want to achieve is like this: I want the program when
>>> compiled to read from a file, parsing the PGM and at the same time
>>> apply transformations to the entries as they are read and write them
>>> back to another PGM file.
>> Such problems are the main motivation for iteratees, conduits, pipes,
>> etc. Every such library contains procedures for doing exactly what you
>> want. Please check Hackage. John Lato's iteratee library, for example,
>> has procedure for handling sound (AIFF) files -- which may be very
>> big. IterateeM has the TIFF decoder -- which is incremental and
>> strict. TIFF is much harder to parse than PGM.

It would be really awesome, though, if it were possible to use a
parser written in Parsec with this, in the spirit of avoiding code
rewriting and enhancing expressivity and abstraction.

More information about the Haskell-Cafe mailing list