ReadP and choice

[Edward Kmett]

On Sat, Feb 25, 2012 at 5:21 PM, Ian Lynagh <igloo at earth.li> 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.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120226/6c1eb06c/attachment.htm>