[Haskell-cafe] Re: Parsec is being weird at me

Chris Casinghino chris.casinghino at gmail.com
Sat Aug 25 17:37:28 EDT 2007

The following two messages didn't make it to the list the first time
because I sent from the wrong address.  oops!  Hopefully these answer
the question.

Message 1:

On 8/25/07, Andrew Coppin <andrewcoppin at btinternet.com> wrote:
> Stefan O'Rear wrote:
> > There is one other little bit of documented behavior.  Parsec's normal
> > combinators only parse LL(1) grammars.  Consult any work on formal
> > languages for the exact meaning and all the consequences, however for
> > this example it serves to note that after seeing abc, the single
> > character of lookahead '#' is not sufficient to determine the correct
> > parse.
> >
> I thought the whole *purpose* of the endBy combinator was to keep
> applying one parser until the other one succeeds?

I don't think this is a lookahead problem, but rather just a
misreading of the spec of endBy.  Here it is:

(endBy p sep) parses zero or more occurrences of p, seperated and
ended by sep. Returns a list of values returned by p.

The key text is "seperated and ended by sep".  Not just ended by.

Of course, the lookahead restriction is real, so just writing

do {s <- many anyToken; char '#'; return s}

won't work either.

I'm not sure there is a built in combinator for what you want, but
you could perhaps write:

do {s <- many (satisfy (/= '#')); char '#'; return s}

perhaps there is a more efficient way.


Message 2:

> I'm not sure there is a built in combinator for what you want,

I guess I should have looked harder.  What you want is manyTill:

"manyTill  :: GenParser tok st a -> GenParser tok st end -> GenParser tok st [a]

(manyTill p end) applies parser p zero or more times until parser end
succeeds. Returns the list of values returned by p."


More information about the Haskell-Cafe mailing list