Am 12.11.2010 01:32, schrieb Derek Elkins:
I would say Parsec 3 is not less up to standard than Parsec 2.
I think, the question should be. Should we bless a (yet missing) Parsec3 library (without compatibility layer) in addition to the current parsec 2 library?
The performance is comparable to Parsec 2, and there are still some things that can be done, as were mentioned in this thread alone. If nothing else, the main example for Parsec 3 being slow, was rerun with Parsec 3.1 and was comparable to Parsec 2.
As far as correctness, the bug reports I've received have mostly been relatively minor and usually have applied to Parsec 2 as well. However, a good unit/regression test suite is definitely something that Parsec (any version) could use. There is, of course, no shortage of systems tests of Parsec that would be quite conspicuous if they failed. I have not gotten a single report along the lines of "I've upgraded to Parsec 3 and now my parser doesn't work."
the compatibility is fine, but mixing both interfaces (Text.Parsec.* and Text.ParserCombinators.Parsec.*) should not be encouraged (and if I don't mix I do not need a compatibility layer).
Parsec 2 has no documentation at all. The Parsec letter is for Parsec 1, but is still quite relevant to all versions of Parsec. The Haddock documentation was added in Parsec 3. Suffice it to say, Parsec 3 is far better than Parsec 2 in this regard. The new features of Parsec have (non-trivial) Haddock documentation, but a documented, significant example using the new features would be a good addition.
the new parsec2 package seems to have the documentation taken from parsec 3.
As far as Don's concerns with regard to stability: As suggested above, most of the emails I've received have been minor bugs that are often in Parsec 2 as well, or feature requests, and there haven't been that many of either. I have no big changes in mind. The next big change I forsee is dropping the compatibility layer at some point. Other than
How should we drop the compatibility layer once it is part of the HP without breaking much code? (Omit the compatibility layer in the first place and ask my initial question!)
that, I can see the Stream class changing significantly, but I believe that can be done in a way that is mostly transparent to users. That is just speculation at this point.
While I agree that currently the monad transformer aspect of Parsec 3
I wonder if Parsec3 is well designed wrt user state, since a user state could be part of the underlying monad. (Could/Would the user state be dropped if compatibility to parsec 2 would be no issue?)
is not a common requirement, the ability to parse ByteStrings and other types (like Text) is certainly something that would be beneficial to many. Parsec 3 runs Parsec 2 code virtually unchanged.
Still, I had a hard time to change my Parsec 2 code to use Bytestrings instead of Strings via Parsec 3.
The only particularly good argument I've seen against having Parsec 3 (v. Parsec 2) in the Platform is the extensions issue.
Unfortunately, most parsers use extensions (even Text.ParserCombinators.ReadP), which makes it difficult for other haskell compilers to profit from the haskell code base. In fact, I wished that the parsec2 modules requiring extensions would be in an extra package. But it seems to be difficult to avoid extensions (as also Parsimony shows) just to support more general streams.
I'm less involved in the Haskell community than I was years ago and I expect that trend to continue a little bit more, and lately I haven't been the best maintainer. I wouldn't want the me right now to be the maintainer for a package in the Haskell Platform, so I've asked Antoine Latter to take up maintainership of Parsec 3 and he has agreed. He's certainly familiar with the code and has been involved in Parsec 3 almost from the beginning. I don't see any trouble during or after the transition. I'll push a minor version upgrade with some pending patches, and then after that it will be Antoine's show. He also doesn't have any big changes planned.
I'm strongly against putting parsec 3 as is into the HP. Creating it as new major of parsec caused enough trouble, moving it into the HP is no good remedy (in my eyes). Christian