On Thu, Feb 11, 2010 at 1:27 PM, Maciej Piechotka <uzytkown...@gmail.com> wrote: > On Thu, 2010-02-11 at 11:00 -0500, Gregory Collins wrote: >> Maciej Piechotka <uzytkown...@gmail.com> writes: >> >> > On Tue, 2010-02-09 at 16:41 +0000, John Lato wrote: >> >> >> >> See http://inmachina.net/~jwlato/haskell/ParsecIteratee.hs for a valid >> >> Stream instance using iteratee. Also Gregory Collins recently posted >> >> an iteratee wrapper for Attoparsec to haskell-cafe. To my knowledge >> >> these are not yet in any packages, but hackage is vast. >> > >> > Hmm. Am I correct that his implementation caches everything? >> >> The one that John posted (iteratees on top of parsec) has to keep a copy >> of the entire input, because parsec wants to be able to do arbitrary >> backtracking on the stream. >> > > Well. Not quite. AFAIU (and ByteString implementation indicate so) the > uncons have a type > uncons :: s -> m (Maybe (t, s)) > > Where s indicates the position on the stream. Since it is impossible to > get back from having s alone the GC should be free to finalize all > memory allocated to cache the stream before the first living s. >
I'm not sure that this is correct - parsec believes that it is free to call 'uncons' multiple times on the same value and receive an equivalent answer. Maybe I'm misunderstanding what we're talking about, but a simple test is: backtrackTest = (try (string "aardvark")) <|> (string "aaple") And then attempt to parse the stream equivalent to "aaple" with 'backtrackTest'. This should be a successful parse (untested). Antoine _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
