Re: Bug in Parsec.Token
derek.a.elkins:
Who is going to maintain "Parsec 4"?
I'm completely against this. If people absolutely must have exactly Parsec 2's implementation we can simply copy it into Parsec 3, and the "compatibility" layer, in that case, will simply -be- Parsec 2. I've considered this as a temporary solution for the performance issues just so people could move to Parsec 3 dependencies, but that should not be necessary now, and even then I considered it a much less than ideal solution.
If the community wants to freeze on Parsec 2, then I have no problem renaming the package, otherwise I think it is both unnecessary and a waste of effort.
The problem is the ongoing lack of confidence in Parsec 3's performance. The new release goes some way to addressing this, but I think this has gone unaddressed for too long. Can someone address the lingering concern with benchmarks against parsec 2? -- Don
Hi, I had a look at parsec-3 and my (first) impression was a shock to see in http://hackage.haskell.org/packages/archive/parsec/3.1.0/doc/html/src/Text-P... <cite> -- Portability : portable [...] {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, UndecidableInstances #-} </cite> whereas the (old) documentation at http://legacy.cs.uu.nl/daan/download/parsec/parsec.html says: <cite> Compatibility The core library is written in Haskell98. </cite> This alone is a reason to prefer parsec-2 over parsec-3. I don't mind more generality for a small speed penalty, but this non-Haskell98 monad-transformer stuff (that I don't need, yet) and that is only documented in a blog (without link from the sources) should be in a separate module (if not package)! I've tried out the compatibility layer. Compiling and parsing works identical for my test cases, but some error messages are different (differences below)! This compatibility layer is useful for testing, but I would not mind to change (or expand) my imports, therefore I think the compatibility layer should also be a separate package. (For some reason I don't like modules much that re-export functions from underlying modules.) Cheers Christian - parsec-2 + parsec-3.1.0 parse error at 2.2: -unexpected "1" -expecting "{", "[", __ or end of input +unexpected '1' +expecting end of input parse error at 3.2: -unexpected "." -expecting "{", "[", __ or end of input +unexpected '.' +expecting end of input parse error at 4.2: unexpected "'" @@ -49,8 +49,8 @@ expecting id parse error at 14.2: -unexpected "b" -expecting "{", "[", __ or end of input +unexpected 'b' +expecting end of input parse error at 15.1: unexpected "as" @@ -64,9 +64,9 @@ unexpected "_" expecting id -parse error at 18.4-18.5: -unexpected "_" -expecting casl char, "{", "[", __ or end of input +parse error at 18.4: +unexpected '_' +expecting end of input parse error at 19.3: unexpected end of input @@ -141,24 +141,24 @@ expecting id parse error at 37.15: -unexpected "<" -expecting __ or end of input +unexpected '<' +expecting end of input parse error at 38.4: -unexpected "=" -expecting "{", "[", __ or end of input +unexpected '=' +expecting end of input parse error at 39.6: -unexpected "%" -expecting __ or end of input +unexpected '%' +expecting end of input parse error at 40.1: unexpected "\"" expecting id parse error at 41.8: -unexpected ">" -expecting __ or end of input +unexpected '>' +expecting end of input
participants (2)
-
Christian Maeder -
Don Stewart