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

[Edward Kmett]

On Mon, Aug 15, 2011 at 3:59 AM, Yitzchak Gale <gale at sefer.org> 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.
>
> There is obviously a consensus in the community to make this change,
> and so be it. Johan is a top professional; I commend his work and all
> others who have contributed to this thread. We all share the common
> goal of improving Haskell.
>
> Now let me repost my previous message, with a bit of commentary
> to ensure that it is interpreted in a strictly objective light:
>
> 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.
>
> Edward mentioned that about 20 of his packages will break.
> For me, a good deal of my professional work for the past half year
> will break. There may be other breakage as well. Even though
> it is not very difficult to fix any individual broken package, I think
> it is fair to call that disruptive.
>
> > 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.
>
> 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.
>
> Perhaps the original suggestion, "+>", is a candidate?
>
> Sebastian Fischer wrote:
> > Why aren't proper imports (as mentioned earlier by Johan) enough
> > to let both versions of <> coexist?
>
> They can only coexist if you do some messy manual renaming
> in each module. Using a non-standard name is confusing and
> makes the code less readable and less maintainable. Re-using the
> standard name in non-standard ways makes the code fragile and
> creates confusing error messages.
>
> 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.
>

I was currently planning on leaving the <> in semigroups untouched. Most of
the time I have to import the bits and pieces of Monoid explicitly anyways,
if (<>) is just a method exported by the module then the packages I have
that import just Monoid(..) from Data.Monoid won't change.

If I have to go through and choose a different operator for it, I go from
having to make (based on grep) about 130 import statement changes that I can
mostly automate with perl, followed by losing a few hours pushing packages,
to having instead to make literally thousands of laborious changes where I
have to carefully examine every one.

Even my OCD has limits. ;)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110815/9b417fe1/attachment.htm>