Hi Twan, You might be interested in a different implementation of the ReadP stuff, namely my Parsek combinator library, which I made some years ago. It tries to mimic Daan Leijen's Parsec library closely, but instead uses the ideas behind the ReadP library. http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/code/week3/Parsek.hs Kind regards, /Koen On 4/11/07, Twan van Laarhoven <twanvl@gmail.com> wrote:
Hi,
Mostly for fun, and to see how well it would work, I made a generalized/improved variant of the ReadP parser library.
Unlike ReadP ParseP can handle any type of token, and actually generates error messages in case something goes wrong. It is also possible to use things other then a list as an input stream, for example ByteStrings.
In addition to the unbiased choice provided by ReadP, and a 'greedy' choice operator similar to the behavior of Parsec (when using try), there is also what I call a 'soft biased' choice. This operator prefers the left alternative, but not if it leads to parse errors later on. For example
runParser ((lit 'a' <<|> return ()) >> lit 'a') "a" will not lead to errors, while it would be an error with other biased choice operators.
An obvious advantage of ParseP over Parsec is that you don't have to mess with 'try'. Also, all alternatives are parsed in parallel, so no backtracking is needed. But I have no idea how the performance would compare in practice.
Also, I am not to happy about the name, does anyone has any other suggestions?
Homepage: http://twan.home.fmf.nl/parsep/ Source: darcs get http://twan.home.fmf.nl/repos/parsep Haddock: http://twan.home.fmf.nl/parsep/doc/html/
Twan _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell