Closed GoogleCodeExporter closed 8 years ago
My main reason for requiring parsec < 3 is performance: pandoc is quite a bit
slower
when compiled with parsec 3. I understand that the parsec 3 developers are
working
on this issue, but until it is resolved, I want to make sure pandoc will build
with
parsec 2 by default.
Original comment by fiddloso...@gmail.com
on 31 Dec 2008 at 2:44
Original comment by fiddloso...@gmail.com
on 13 Jul 2009 at 3:03
Does parsec 3.1 change things?
http://www.haskell.org/pipermail/haskell-cafe/2010-March/074076.html
Original comment by eric....@gmail.com
on 4 Apr 2010 at 10:04
I think that parsec 3.1 does fix the performance problems. But I'm still
reluctant to
change the default, for the following reason. You'll get problems if you try
to link
libraries compiled against parsec 3 with libraries compiled against parsec 2.
There
are still lots of libraries that require parsec 2, so I think that the whole
community
has to decide to make the change to parsec 3, or there will be problems linking
pandoc with those libraries.
Two possible ways forward:
- whole community can decide to lift the parsec < 3 restrictions.
- we can rename one of the packages, as was suggested on one of the haskell
lists,
either naming parsec 2 "parsec98", or renaming parsec 3. Then the link
conflict
problem goes away.
I think the second solution is best, myself.
Original comment by fiddloso...@gmail.com
on 4 Apr 2010 at 4:29
PS. I could, in the mean time, add a cabal flag that allows pandoc to be built
against
parsec 3 (defaulting to False), if that would be useful.
Original comment by fiddloso...@gmail.com
on 4 Apr 2010 at 4:31
Original issue reported on code.google.com by
L.Plant...@cantab.net
on 30 Dec 2008 at 11:41