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