ReadP and choice

Edward Kmett ekmett at
Sun Feb 26 18:15:16 CET 2012

On Sat, Feb 25, 2012 at 5:21 PM, Ian Lynagh <igloo at> wrote:

> Hi all,
> The code below defines a ReadP parser which can parse either a keyword
> "wrapper" or an arbitrary identifier. I was hoping that it would give
> the output
>    (CWrapper1,"")
>    (CWrapper2,"")
>    (CFunction "wrapper","")
> but it actually gives
>    (CWrapper2,"")
>    (CFunction "wrapper","")
>    (CWrapper1,"")
> i.e. completed parses are returned before the parse that needs to "look"
> at the remaining input.

I can see the logic behind the current behaviour, but in this case at
> least it's quite inconvenient.
> What do you think?
> Did I miss a better way to solve the problem?
> Should the behaviour be changed?
> If so, is changing it easy?

This is because ReadP is breadth first and the results are returned as they
are determined.

Can you get away with switching to (<++) , which will let you more or less
pretend you are using a biased parser like parsec and will only give you
the single result you want?

Any change to ReadP that sorts the current breadth-first search state is
going to incur an asymptotic increase in overhead when you have multiple
parses and I don't think it would be a good idea.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list