On 3/28/06, Neil Mitchell <[EMAIL PROTECTED]> wrote: > > This feels like a situation Parsec users would find themselves in all the > > time. When you have a bunch of parsers in a 'choice', does the start of the > > input stream linger until the last parser is executed? > > No, as soon as one token is accepted from any parser, that input is > decided upon, and it will never go back. If you want that behaviour > you have to wrap the particular parser in try, which does give the > backtracking (and space leak) > I personally find this behaviour terribly confusing. It makes writing the parser highly unmodular. It forces me to know exactly what a certain parser recognizes to know whether I need to wrap a 'try' around it when I compose it in parallel with another parser. Which is why I much prefer to use parsing libraries based on Koen Claessen's technique which performs all parses at the same time. It works breadth-first on the parse forest (the set of parse trees). Text.ParserCombinators.ReadP is one example which uses this technique.
Cheers, /Josef _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
