Proposal #3339: Add (+>) as a synonym for mappend

[Edward Kmett]

What I'm doing is pushing out a new major version of semigroups that adds
the export of Monoid(..) to the subset of Data.Monoid that it re-exports.
I'm also changing its associativity to the right to match the one that tibbe
is going to put into Data.Monoid.

This is arguably better behavior as it causes <> to be incompatible with +
so you have to parenthesize (good), but associates to the right so that
libraries like pretty printers (those which didn't have the foresight to use
codensity to fix up the asymptotics of left associated <>) get the right
asymptotic behaviors.

This way if you want to work with semigroups and monoids you

import Data.Semigroup

And if you want to work with monoids using the <> operator, then you

import Data.Monoid

This will let me more or less just go through and delete the import
Data.Monoid lines from each of my other packages,
and means that the users of semigroups don't have to muck around with
qualified imports.

Semantically the fact that Data.Semigroup exports Monoid is a bit wrong, but
it is less wrong than forcing every user to juggle qualified imports.

Malcolm sent out a downstream list for semigroups, almost all of the direct
dependencies are mine.

I will make this change immediately to my other libraries.

The indirect dependencies don't import Data.Semigroup and as of last week, I
no longer re-export Data.Semigroup from any package, so the indirect
dependencies should have no problems.

-Edward

On Mon, Aug 15, 2011 at 11:09 AM, Yitzchak Gale <gale at sefer.org> wrote:

> Sebastian Fischer wrote:
> > The proposal is not to replace 'mappend' in the Monoid class with <>. The
> > proposal is to add the top-level definition
> >     (<>) = mappend
> > to Data.Monoid.
>
> Thanks Sebastian, you're right, I misread that. I wouldn't have
> made nearly as much noise then. It's still bad to have two
> definitions of <> that appear to be the same but are in reality
> two different functions. But in the short term, that won't cause
> me nearly as much damage.
>
> In the long term, it is perhaps worse. It means that now even
> superclass defaulting won't completely solve the problem -
> you can silently get the wrong function without noticing.
> That would be a very difficult bug to find.
>
> Note that this is worse than, for example, libraries that shadow
> Prelude functions. There, if you don't use the right qualified/hiding
> incantation, you'll generally get a compile error.
>
> Anyway, I apologize for grossly overreacting. If anyone needs
> me in the near future, please look inside the hole I am
> currently digging for myself.
>
> Thanks,
> Yitz
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110815/ccccec20/attachment.htm>