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

[Conor McBride]

Yitz

On 15 Aug 2011, at 08:59, Yitzchak Gale wrote:

> It has been pointed out to me that my previous message in this
> thread could be interpreted as having personal overtones.
> Given my strident tone in the rest of this thread that is
> understandable, but it really wasn't my intention. I apologize
> if anyone took offense from that or any other of my posts.

Let me be clear that I hadn't even begun to think about being
offended. You raise entirely reasonable concerns.

[..]

> Conor McBride wrote:
>>> http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
>>> I don't know if it's likely to be implemented in GHC anytime soon,..
>>> So things are looking up. It should soon be technically feasible to
>>> separate the issues of whether the Monoid operator should be (<>)  
>>> and
>>> whether it should actually live in a Semigroup superclass...
>
> I wrote:
>> Nice. But will it be happening soon, or not? And how soon is soon?
>> It looks like Johan will soon be committing a disruptive change
>> that will break many packages.

I don't know. I'm not a GHC hacker and I'm unlikely to catch enough  
breath
to become one in 2011. But perhaps someone will volunteer. The proposal
amounts to a scheme for chopping up complex instances into bits. Unless
GHC is weirder than I imagine, it shouldn't be a huge effort for someone
who already knows what they're doing.

>
>> Is it necessary for the semigroups
>> package to change the name of <> in order to make it
>> possible to fix the broken packages in a reasonable way, or will this
>> better facility likely become available within approximately the same
>> time frame as the breaking change?
>
> It would be great if Conor's new feature gets implemented around
> the same time as the change. Then the damage would be minimal;
> we can just hold back some package versions for a short while, and
> everything will eventually sort itself out.

I wish I was in a position to do more than agree. (I can't, of course,
claim credit for the feature: most of the ideas were out there already,
so my job was merely an editorial one.) The whole point is to allow
low-damage re-engineering of type class hierarchies whilst preserving
old interfaces. We have too many of these painful discussions for the
want of better software engineering.

And it's probably not a good idea to make these packages depend on SHE.
Mind you, I did just do Monad-Applicative-Functor that way, and it
worked out quite sweetly in the Epigram codebase.

> But if not, it would be good if the name of <> in Data.Semigroup were
> changed to something else before Johan's change propagates. That
> would make the required fixes a lot less messy.

Renaming away is traditional. Another lament: alpha-coversion is too
difficult, and for no good reason!

[..]

> If we change the name of <> to +> (or something) in semigroups,
> at least the situation will be no worse than for "pure" in
> Applicative vs. "return" in Monad.

That's right. And when default superclass instances happens, there
ought to be a bit of a purge. Applicative will steal "return" from
Monad, with pure as a deprecated synonym. The same could happen here.
(Ha! Maybe the deprecation warnings could be emitted as sed commands,
or a patch file!)

Let's see if we can get a steer on superclasses from an insider...
It's unfortunate if it comes to renaming-away, but I suspect
standardising an infix mappend has quite a high value.

Sorry not to be more definitive

Conor