ANN: new version of uu-parsinglib
A new version of the uu-parsinglib has been uploaded to hackage. It is now based on Control.Applicative where possible. Be warned that functions like some and many will be redefined in the future. Doaitse Swierstra
On Sun, May 31, 2009 at 09:40:38PM +0200, S. Doaitse Swierstra wrote:
A new version of the uu-parsinglib has been uploaded to hackage. It is now based on Control.Applicative where possible.
Be warned that functions like some and many will be redefined in the future.
Perhaps we should make some and many methods of Alternative, <* and *> methods of Applicative and <$ a method of Functor, all with the current definitions as defaults. (John Meacham was also asking for the first of these.)
And rename "empty" to "fail"? You managed to confuse me since I always use pSucceed to recognise the empty string. Doaitse On 1 jun 2009, at 01:21, Ross Paterson wrote:
On Sun, May 31, 2009 at 09:40:38PM +0200, S. Doaitse Swierstra wrote:
A new version of the uu-parsinglib has been uploaded to hackage. It is now based on Control.Applicative where possible.
Be warned that functions like some and many will be redefined in the future.
Perhaps we should make some and many methods of Alternative, <* and *> methods of Applicative and <$ a method of Functor, all with the current definitions as defaults. (John Meacham was also asking for the first of these.) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Mon, Jun 01, 2009 at 08:27:05PM +0200, S. Doaitse Swierstra wrote:
And rename "empty" to "fail"? You managed to confuse me since I always use pSucceed to recognise the empty string.
That would clash with the existing and widely used "fail". One could view "empty" as the parser for the empty language. And some of us are also interested in Alternatives that aren't parsers.
On Sun, May 31, 2009 at 7:21 PM, Ross Paterson
Perhaps we should make some and many methods of Alternative, <* and *> methods of Applicative and <$ a method of Functor, all with the current definitions as defaults. (John Meacham was also asking for the first of these.)
+1 As a justification, (*>) and (>>) serve much the same purpose, and (>>) is already exposed via Monad to permit the same kinds of optimizations that an explicit override of (*>) proffers. -Edward Kmett
participants (4)
-
Conor McBride -
Edward Kmett -
Ross Paterson -
S. Doaitse Swierstra