Bug in Parsec.Token
s.clover at gmail.com
Fri Apr 2 11:36:26 EDT 2010
Ganesh Sittampalam wrote:
> The parsec98 name sounds cool, but if used, it'll last a long time I
> think it'll just be sowing more confusion for a future in which the
> origins of the name have faded into obscurity. And what if someone
> wants to keep it roughly as is, but bring it up to date with the
> latest Haskell standard? The name would be rather a barrier then.
> If versions are going to be forked off, let's aim for a consistent
> naming scheme - parsec2, QuickCheck1, etc. Not sure how to deal with
> HaXml 1.13 (the other strong candidate for this kind of treatment).
+1 to the idea of doing this as a general practice, and to all the
particulars raised. Just like a package broken by the new exceptions can
always switch to importing old-exception for the time being, it should
be similarly easy for people to remain stable on parsec, quickcheck,
haxml and such for some time to come -- not even necessarily to
encourage this, but simply because it makes a uniform treatment of
legacy code much more manageable.
More information about the Libraries