Claus Reinke wrote:
ah, that suggests yet another specification, a variation of the second
version above, where the parser in control is not p1 itself, but p2,
with p1 acting as an input transformation for p2, and p3 resuming
where p1 left off. the difference being that p2's demand is supposed
to drive p1's input processing. which is a bit of a problem.
Yep, that's the one.
parsers are usually data- and grammar-driven, not demand-driven, ie
the input consumed by p1 does not usually depend on the demands on
p1's output.
Yeah, I realise that. ;-)
I did wonder if Parsec's #include mechanism could do it - but apparently
not. So I wrote my own...
looking a little bit more closely, however, p1 is used more as a
piecewise input transformation for p2 than as a separate parser. so it
makes more sense to integrate p1 into p2.
Possibly - except that I want to be able to stack any decoder on top of
any decoder. For *output* this is a trivial matter of function
composition. For input, this presents the tricky parsing problem we're
now discussing...
that seems to be what you have in mind with your stacked approach,
where the state is read exclusively through the fetch method in the
Source interface, and a Source can either be a plain list or buffered
item parser stacked on top of a Source (where fetch is served from the
buffer, which is replenished by running the item parser over the inner
Source; btw, are unused buffer contents discarded when p2 finishes?
they can't be transformed back into p1/p3's input format..).
That's right.
(And yes, the idea is that the buffer should *always* be empty when the
top parser exits. Assuming the data stream was built correctly in the
first place, this should always hold...)
instead of using a type class, one could also parameterise p2 by its
item parser, 'fetch'.
Mmm... that's an interesting idea. I'll have to have a think about that...
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
