While I like the idea of (++) as mappend to some extent, two objections immediately come to mind: 1.) While I like the appeal to the PVP to export a version of (++) from Data.Monoid and I think this has worked out well for new modules like Control.Category, I'm not sure that with a module that has been around for so long as Data.Monoid can be so flippant about breaking any code that imports it unqualified that also happens to use a list. Lists are everywhere in Haskell, and unqualified imports do exist.
2.) There is also a pretty big caveat in that the choice of which operator should be naturally selected for (++) _is_ ambiguous. Should it be mappend or mplus? Recall that in Haskell 1.4 (++) worked on MonadPlus and it was changed in the great monomorphism revolution of '98. -Edward Kmett On Sun, Jul 5, 2009 at 4:41 PM, Henning Thielemann < [email protected]> wrote: > > On Tue, 30 Jun 2009, Bryan O'Sullivan wrote: > > I've thought for a while that it would be very nice indeed if the Monoid >> class had a more >> concise operator for infix appending than "a `mappend` b". I wonder if >> other people are of a >> similar opinion, and if so, whether this is worth submitting a >> librar...@proposal over. >> > > We have the package version policy which relies on explicit or qualified > imports, such that adding a function like (++) to Data.Monoid cannot harm > any package that follow that policy. Thus I vote for not introducing a new > operator, in order to keep the set of infix operators to memorize small, but > use (++) for the generalized (List.++) aka mappend. The user would however > need to hide (++) from Prelude. > > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
