<div class="gmail_quote">On Thu, Jun 2, 2011 at 7:02 AM, Yitzchak Gale <span dir="ltr">&lt;<a href="mailto:gale@sefer.org">gale@sefer.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It seems the best I can do is to collect them all in a list and then<br>
apply concat. But that still copies the text several times.<br></blockquote><div><br></div><div>Right. I&#39;d like a no-copy combinator for the same reasons, but I think it&#39;s impossible to do without some low-level support.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If not, does the internal representation easily admit such a combinator?<br></blockquote><div><br></div><div>
Not very easily. Internally, attoparsec maintains just three pieces of data for its state:</div><div><ul><li>The current input</li><li>Any input we received via continuations, in case we need to backtrack</li><li>A flag that denotes whether we were fed EOF by a continuation</li>
</ul>There are no line numbers, no &quot;bytes consumed&quot; counters, nothing else. If there was a &quot;bytes consumed&quot; counter, it would be possible to write a &quot;try&quot;-like combinator that would hold onto the current input, run a parser, tack on any input received via continuations to the original input, and then use the counter to slice off a portion of that bytestring without copying. I can&#39;t think of another way to do it. Adding that counter would be a moderate amount of work, and would presumably have a negative effect on performance.</div>
</div>