Claus Reinke wrote:
source code is always useful, as it is concrete. but some comments about
purpose and important aspects would help, too, lest we optimise away the
parts you're most interested in. as it stands, i must assume that
'decodeRLEb' is the purpose of the exercise, and it isn't clear to me
why that requires nested or otherwise nontrivial parsers?
Now take decodeRLEb and feed it's output to some nontrivial parser, and
then feed the remainder of the input, unmodified, into another parser:
foo = do
x <- stack () decodeRLEb () other_stuff
y <- bar
return (x,y)
Since I don't know how much data other_stuff is going to consume - let
alone how much of the raw data you have to feed to decodeRLEb to make
that much data - we arrive at the structure shown.
(This makes it, what, the 5th time I've explained this? LOL...)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
