On Sat, Feb 25, 2012 at 5:21 PM, Ian Lynagh <span dir="ltr">&lt;<a href="mailto:igloo@earth.li" target="_blank">igloo@earth.li</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Hi all,<br>
<br>
The code below defines a ReadP parser which can parse either a keyword<br>
&quot;wrapper&quot; or an arbitrary identifier. I was hoping that it would give<br>
the output<br>
    (CWrapper1,&quot;&quot;)<br>
    (CWrapper2,&quot;&quot;)<br>
    (CFunction &quot;wrapper&quot;,&quot;&quot;)<br>
but it actually gives<br>
    (CWrapper2,&quot;&quot;)<br>
    (CFunction &quot;wrapper&quot;,&quot;&quot;)<br>
    (CWrapper1,&quot;&quot;)<br>
i.e. completed parses are returned before the parse that needs to &quot;look&quot;<br>
at the remaining input.<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can see the logic behind the current behaviour, but in this case at<br>
least it&#39;s quite inconvenient.<br>
<br>
What do you think?<br>
Did I miss a better way to solve the problem?<br>
Should the behaviour be changed?<br>
If so, is changing it easy?</blockquote><div><br></div><div>This is because ReadP is breadth first and the results are returned as they are determined.</div><div><br></div><div>Can you get away with switching to (&lt;++) , 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?</div>

<div> </div><div>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&#39;t think it would be a good idea.</div>

<div><br></div><div>-Edward</div></div>