[Haskell-cafe] A very nontrivial parser

[Andrew Coppin]

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...