On 12 September 2012 11:46, Eric Velten de Melo <ericvm...@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, <o...@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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
