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