
Hi, Am Montag, den 02.08.2010, 06:34 -0500 schrieb Antoine Latter:
On Mon, Aug 2, 2010 at 6:32 AM, Antoine Latter
wrote: On Mon, Aug 2, 2010 at 1:55 AM, Ivan Miljenovic
wrote: That said, if parsec2 is only a bug-fix branch of parsec-2.x, is there any particular reason work couldn't be done to improve the performance of parsec-3 when using the compatibility layer (and even improving the performance of parsec-3 overall) rather than a specific branch/fork?
The release of parsec-3.1 dramatically improved the performance of parsec3 to roughly parsec-2.1 levels. So I don't know of any downside to switching over to the compatibility layer other the fact that it's a much newer code-base, and that it's a much further departure
How about I finish my sentences.
My second downside was that parsec-3 is a much further departure from Haskell2010 than parsec-2.
with my Debian Haskell Group hat on, I would very much welcome a convergence on _one_ parsec package, so that we don’t have to package two. I’m happy with patching existing packages to use a parsec3 compatibility layer as long as the required changes are of the trivial, type-checked kind or only affect the .cabal file :-). But I do need some assurance that parsec3 is ready to replace parsec2, both performance and reliability-wise. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org