<div class="gmail_quote">On Thu, Jul 29, 2010 at 10:55 AM, Jason Dagit <span dir="ltr"><<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>Given those constructors for Result, how will you decode a sequence lazily?</div></div></blockquote><div><br></div><div>I deliberately left incremental results out of the attoparsec API, because it's a burrito-filled spacesuit of worms.</div>
<div><br></div><div>The problem is that parsers can nest and fail and backtrack and be, in general, arbitrarily perverse. For instance, if there was a "yield" action, I could yield you a 1, backtrack, then yield you a 10 from some completely different branch of the parser that neither I nor you could foresee.</div>
<div><br></div><div>Now, lazily parsing a sequence of data is a very common need, and it's also highly constrained, and hence easy to predict. It's also something that's easy to write without any access to the attoparsec internals. It would take just a few moments to write this:</div>
<div><br></div><div>parseSequence :: Parser a -> Lazy.ByteString -> [a]</div><div><br></div><div>I haven't added this to attoparsec because it's (a) trivial and (b) just one possible approach. Using iteratees would be another; running with a monadic action that can refill the parser on a Partial result would be yet another.</div>
</div>