<div class="gmail_quote">On Mon, Aug 15, 2011 at 3:59 AM, Yitzchak Gale <span dir="ltr"><<a href="mailto:gale@sefer.org">gale@sefer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
It has been pointed out to me that my previous message in this<br>
thread could be interpreted as having personal overtones.<br>
Given my strident tone in the rest of this thread that is<br>
understandable, but it really wasn't my intention. I apologize<br>
if anyone took offense from that or any other of my posts.<br>
<br>
There is obviously a consensus in the community to make this change,<br>
and so be it. Johan is a top professional; I commend his work and all<br>
others who have contributed to this thread. We all share the common<br>
goal of improving Haskell.<br>
<br>
Now let me repost my previous message, with a bit of commentary<br>
to ensure that it is interpreted in a strictly objective light:<br>
<div class="im"><br>
Conor McBride wrote:<br>
>> <a href="http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances" target="_blank">http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances</a><br>
>> I don't know if it's likely to be implemented in GHC anytime soon,..<br>
>> So things are looking up. It should soon be technically feasible to<br>
>> separate the issues of whether the Monoid operator should be (<>) and<br>
>> whether it should actually live in a Semigroup superclass...<br>
<br>
</div><div class="im">I wrote:<br>
> Nice. But will it be happening soon, or not? And how soon is soon?<br>
> It looks like Johan will soon be committing a disruptive change<br>
> that will break many packages.<br>
<br>
</div>Edward mentioned that about 20 of his packages will break.<br>
For me, a good deal of my professional work for the past half year<br>
will break. There may be other breakage as well. Even though<br>
it is not very difficult to fix any individual broken package, I think<br>
it is fair to call that disruptive.<br>
<div class="im"><br>
> Is it necessary for the semigroups<br>
> package to change the name of <> in order to make it<br>
> possible to fix the broken packages in a reasonable way, or will this<br>
> better facility likely become available within approximately the same<br>
> time frame as the breaking change?<br>
<br>
</div>It would be great if Conor's new feature gets implemented around<br>
the same time as the change. Then the damage would be minimal;<br>
we can just hold back some package versions for a short while, and<br>
everything will eventually sort itself out.<br>
<br>
But if not, it would be good if the name of <> in Data.Semigroup were<br>
changed to something else before Johan's change propagates. That<br>
would make the required fixes a lot less messy.<br>
<br>
Perhaps the original suggestion, "+>", is a candidate?<br>
<div class="im"><br>
Sebastian Fischer wrote:<br>
> Why aren't proper imports (as mentioned earlier by Johan) enough<br>
> to let both versions of <> coexist?<br>
<br>
</div>They can only coexist if you do some messy manual renaming<br>
in each module. Using a non-standard name is confusing and<br>
makes the code less readable and less maintainable. Re-using the<br>
standard name in non-standard ways makes the code fragile and<br>
creates confusing error messages.<br>
<br>
If we change the name of <> to +> (or something) in semigroups,<br>
at least the situation will be no worse than for "pure" in<br>
Applicative vs. "return" in Monad.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>Even my OCD has limits. ;)</div><div><br></div><div>-Edward</div></div>