On 12 September 2012 11:46, Eric Velten de Melo 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, 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.

On 9/12/12 5:37 PM, Francesco Mazzoli wrote:

At Wed, 12 Sep 2012 12:04:31 -0300, Eric Velten de Melo wrote:

...

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.

There is http://hackage.haskell.org/package/attoparsec-conduit and http://hackage.haskell.org/package/attoparsec-enumerator, which turn attoparsec parsers into enumerators/conduits, and http://hackage.haskell.org/package/attoparsec-parsec, which is a compatibility layer between attoaparsec and parsec. Good luck :).

Not to mention attoparsec-iteratee, for the iteratee minded folks: http://hackage.haskell.org/package/attoparsec-iteratee -- Live well, ~wren

On 9/14/12 5:16 PM, Eric Velten de Melo wrote:

But now I'm kinda lost. Is there an easy way to explain the difference between: -iteratee -conduit -enumerator

John Lato's iteratee library is the original one based on Oleg Kiselyov's work. I've used it a fair deal and am quite fond of it. Some folks didn't like it so much though; whence enumerator, conduit, pipes, pipes-core,... I've followed the discussions back and forth over those libraries, but I've not used them nor sat down to compare them head-to-head. -- Live well, ~wren