On Mon, Aug 15, 2011 at 3:59 AM, Yitzchak Gale
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