Re: Proposal #3339: Add (+>) as a synonym for mappend
On Sun, Aug 14, 2011 at 6:54 PM, Yitzchak Gale
Johan Tibell wrote:
This doesn't work well unless SemiGroup is a superclass of Monoid. For example, class constraints would have to include redundant information
Just like for Functor and Monad, Applicative and Monad, etc.
Right. And we have no good way of fixing that, so until we do we leave it alone. The same goes for a different numerical tower etc. However, we can add an operator for monoids, making them easier to use. When we have the language means to add SemiGroups in a way that makes sense, we'll do so. We don't at the moment. We're not going to stop changing base because someone added an operator with the same name as we'd like to use in some package on Hackage.
Semigroup should have been defined at the same time as Monoid. But it wasn't.
In general it's not possible to predict all the levels can could potentially exists "above" a type class. That doesn't mean we shouldn't define the type class we know of at the moment.
This proposal is exactly analogous to proposing that we rename 'return' to 'pure', because it is shorter. And because, after all, Monad is use much more than Applicative. But that would obviously be really wrong. You can already use 'pure' instead of 'return' - just make sure that the Monad also has an Applicative instance. Bother the library author if it doesn't have one yet. Making that change would cause a huge mess.
No it's not the same. Renaming return to pure would break lots of code. Adding <> doesn't have anywhere near the same implications.
Haven't we learned anything from the years of plodding through the Functor - Applicative - Monad situation, and other problems with the class system? Until we get a way of fixing those things, please, let's think very carefully before we make changes like this that have a potential for widespread long-term damage.
There's no way to be careful in this sense. The number of potential superclasses is unknown. Lets instead focus on a way to deal with that. Cheers, Johan
I think I've made my position clear, so I'm going to stop beating the drum and giving everyone a headache. But for a different reason, I feel I do need to respond to one more comment: Johan Tibell wrote:
We're not going to stop changing base because someone added an operator with the same name as we'd like to use in some package on Hackage.
That is really not fair to Edward. He is not just "someone" - he is one of today's leading contributors to Haskell's ecosystem, both in quantity and in quality. When he makes a contribution directed at a general audience, like this one, it is intuitive, practical, performant, elegant, carefully considered, and based on deep theoretical harmony. Edward did not just add "an operator with the same name". He implemented this ticket, the right way. It's done. You can already use <> today - just say "import Data.Semigroup ((<>))". If you want to put that in base, go right ahead. Please don't imply that I am against making changes to base in general. The reason we came to this situation in the first place is that the original proposal languished for so long. At least this time, whatever we decide will be implemented right away. :) As I type this, Edward himself has come out in favor of the original proposal, thus breaking all code based on his own package. So I guess that settles it. Thanks, Yitz
On Sun, Aug 14, 2011 at 4:20 PM, Yitzchak Gale
I think I've made my position clear, so I'm going to stop beating the drum and giving everyone a headache. But for a different reason, I feel I do need to respond to one more comment:
Johan Tibell wrote:
We're not going to stop changing base because someone added an operator with the same name as we'd like to use in some package on Hackage.
That is really not fair to Edward. He is not just "someone" - he is one of today's leading contributors to Haskell's ecosystem, both in quantity and in quality. When he makes a contribution directed at a general audience, like this one, it is intuitive, practical, performant, elegant, carefully considered, and based on deep theoretical harmony.
Edward did not just add "an operator with the same name". He implemented this ticket, the right way. It's done. You can already use <> today - just say "import Data.Semigroup ((<>))". If you want to put that in base, go right ahead.
Please don't imply that I am against making changes to base in general. The reason we came to this situation in the first place is that the original proposal languished for so long. At least this time, whatever we decide will be implemented right away. :)
As I type this, Edward himself has come out in favor of the original proposal, thus breaking all code based on his own package. So I guess that settles it.
Thank you for the support. In a perfect world, I would like to have the (<>) operator be in semigroup and the monoid class just lose mappend, being just mempty. This would let us fix the broken monoid instance for Maybe, dropping the need for Option in the semigroups package and let us introduce nice Min and Max semigroups. But I could live with the (<>) = mappend compromise. I'm sure it somehow makes someone somewhere happier than doing the right thing. -Edward
Thanks, Yitz
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Sun, Aug 14, 2011 at 16:20, Yitzchak Gale
As I type this, Edward himself has come out in favor of the original proposal, thus breaking all code based on his own package. So I guess that settles it.
He quite reasonably chose compatibility with the existing ecosystem over dependency on a massive restructuring. Not that that restructuring is a bad idea, but without better language support it's simply not worth the effort. Speaking of which, has anyone formally proposed the class/instance alias stuff for GHC? If so, has anyone stepped in to implement it? Having the tools to actually make this kind of change would be helpful. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
On 14 Aug 2011, at 21:26, Brandon Allbery wrote:
Speaking of which, has anyone formally proposed the class/instance alias stuff for GHC? If so, has anyone stepped in to implement it? Having the tools to actually make this kind of change would be helpful.
*ahem* http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances I don't know if it's likely to be implemented in GHC anytime soon, but SHE has something rather like it (ie, it's so simple, a preprocessor can do it). A key motivation is exactly to minimise (but the minimum is not zero) the damage done in the situation envisaged here. In particular, it should be possible to add (<>) as a method to Monoid, then, at a later date, split off Semigroup, taking (<>) with it, leaving existing Monoid instances still valid (as they would implicity spawn Semigroup instances). The nasty cases are when you want to define liftings where Monoid x => Monoid (Lift x), but Semigroup x => Semigroup (Lift x). The proposal as it stands would leave Monoid x => Semigroup (Lift x) which might sometimes (but not all the time) be weaker than one has the right to. Other bits of class alias stuff (constraint synonyms) seem to be happening round about now, somewhere in the vicinity of Cambridge. 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, pretty much allowing neither, either or both-in-either-order adoption strategies. Hoping this helps Conor
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...
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. 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? Thanks, Yitz
This is a call for consensus. Do we agree to add
infixr 6 <>
+1 Johan wrote:
Renaming return to pure would break lots of code. Adding <> doesn't have anywhere near the same implications.
Yitzchak wrote: It looks like Johan will soon be committing a disruptive change
that will break many packages.
What are those many packages that will break?
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,
Why aren't proper imports (as mentioned earlier by Johan) enough to let both versions of <> coexist? Sebastian
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. Thanks, Yitz
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
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
Edward Kmett wrote:
I was currently planning on leaving the <> in semigroups untouched... if (<>) is just a method exported by the module then the packages I have that import just Monoid(..) from Data.Monoid won't change.
Hmm, why not? If two different functions named <> are imported via Monoid(..) and Semigroup(..), I don't think the compiler will find that humorous. Are you going to use qualified operators?
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.
Yes, I am also facing days of tedious work to dig out of this. I would love to find automation opportunities, but I don't understand how what you are suggesting can help. I'd also like to coordinate and do things in a standard way as much as possible, to salvage as much readability as we can. Thanks, Yitz
Here are the 24 packages that directly depend on the semigroups package, and may need to be audited as a consequence of the proposed change to Data.Monoid: http://81.26.216.99/~roel/cgi-bin/hackage-scripts/revdeps/semigroups-0.7.1.2...
All of the direct reverse dependencies are now updated.
-Edward Kmett
On Mon, Aug 15, 2011 at 6:31 AM, Malcolm Wallace
Here are the 24 packages that directly depend on the semigroups package, and may need to be audited as a consequence of the proposed change to Data.Monoid:
http://81.26.216.99/~roel/cgi-bin/hackage-scripts/revdeps/semigroups-0.7.1.2...
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Hi Yitzchak,
On Mon, Aug 15, 2011 at 7:14 PM, Yitzchak Gale
Edward Kmett wrote:
if (<>) is just a method exported by the module then the packages I have that import just Monoid(..) from Data.Monoid won't change.
Hmm, why not? If two different functions named <> are imported via Monoid(..) and Semigroup(..), I don't think the compiler will find that humorous.
The proposal is not to replace 'mappend' in the Monoid class with <>. The proposal is to add the top-level definition (<>) = mappend to Data.Monoid. Importing Monoid(..) does not import the new <> and people who import (or define) another definition of <> can hide the new operator from Data.Monoid. I am also facing days of tedious work to dig out of this.
I would love to find automation opportunities, but I don't understand how what you are suggesting can help.
If you already use explicit imports, then you don't need to change anything. If you don't, you can replace import Data.Monoid with import Data.Monoid hiding ((<>)) or, for backwards compatibility, with an import statement that imports explicitly what you use. Sorry, if that was obvious to you.. Best regards, Sebastian
Sebastian Fischer wrote:
The proposal is not to replace 'mappend' in the Monoid class with <>. The proposal is to add the top-level definition (<>) = mappend to Data.Monoid.
Thanks Sebastian, you're right, I misread that. I wouldn't have made nearly as much noise then. It's still bad to have two definitions of <> that appear to be the same but are in reality two different functions. But in the short term, that won't cause me nearly as much damage. In the long term, it is perhaps worse. It means that now even superclass defaulting won't completely solve the problem - you can silently get the wrong function without noticing. That would be a very difficult bug to find. Note that this is worse than, for example, libraries that shadow Prelude functions. There, if you don't use the right qualified/hiding incantation, you'll generally get a compile error. Anyway, I apologize for grossly overreacting. If anyone needs me in the near future, please look inside the hole I am currently digging for myself. Thanks, Yitz
What I'm doing is pushing out a new major version of semigroups that adds
the export of Monoid(..) to the subset of Data.Monoid that it re-exports.
I'm also changing its associativity to the right to match the one that tibbe
is going to put into Data.Monoid.
This is arguably better behavior as it causes <> to be incompatible with +
so you have to parenthesize (good), but associates to the right so that
libraries like pretty printers (those which didn't have the foresight to use
codensity to fix up the asymptotics of left associated <>) get the right
asymptotic behaviors.
This way if you want to work with semigroups and monoids you
import Data.Semigroup
And if you want to work with monoids using the <> operator, then you
import Data.Monoid
This will let me more or less just go through and delete the import
Data.Monoid lines from each of my other packages,
and means that the users of semigroups don't have to muck around with
qualified imports.
Semantically the fact that Data.Semigroup exports Monoid is a bit wrong, but
it is less wrong than forcing every user to juggle qualified imports.
Malcolm sent out a downstream list for semigroups, almost all of the direct
dependencies are mine.
I will make this change immediately to my other libraries.
The indirect dependencies don't import Data.Semigroup and as of last week, I
no longer re-export Data.Semigroup from any package, so the indirect
dependencies should have no problems.
-Edward
On Mon, Aug 15, 2011 at 11:09 AM, Yitzchak Gale
Sebastian Fischer wrote:
The proposal is not to replace 'mappend' in the Monoid class with <>. The proposal is to add the top-level definition (<>) = mappend to Data.Monoid.
Thanks Sebastian, you're right, I misread that. I wouldn't have made nearly as much noise then. It's still bad to have two definitions of <> that appear to be the same but are in reality two different functions. But in the short term, that won't cause me nearly as much damage.
In the long term, it is perhaps worse. It means that now even superclass defaulting won't completely solve the problem - you can silently get the wrong function without noticing. That would be a very difficult bug to find.
Note that this is worse than, for example, libraries that shadow Prelude functions. There, if you don't use the right qualified/hiding incantation, you'll generally get a compile error.
Anyway, I apologize for grossly overreacting. If anyone needs me in the near future, please look inside the hole I am currently digging for myself.
Thanks, Yitz
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
(Adding GHC users, and changing title.) | 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... | | Nice. But will it be happening soon, or not? And how soon is | soon? Not soon enough to be useful for this mappend question. But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about (a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"? (b) What is the "right" design? (c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything) With help from Conor we have made some progress on this: we have a draft design: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances If you care about the issue, maybe you can help resolve the above questions. In particular, to give concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point. If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful. I am in too many inner loops. But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98. Simon
Hi Simon On 15 Aug 2011, at 11:36, Simon Peyton-Jones wrote:
| Nice. But will it be happening soon, or not? And how soon is | soon?
Not soon enough to be useful for this mappend question.
But, concerning proposed extensions to GHC about class aliases/ superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about
(a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"?
(b) What is the "right" design?
(c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything)
If you care about the issue, maybe you can help resolve the above questions. In particular, to give concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point.
I can't speak for "typical" users, but I can relay my own experience. I added this feature to SHE last time there was an outbreak of Functor/Applicative/Monad, just to focus a bit of concrete thought on the matter. Hacking on Epigram the other day, I finally got annoyed enough (with dumb extra instances) to use it, so I wired in default superclass instances Functor for Applicative, Applicative for Monad Functor for Traversable, Foldable for Traversable Alternative for MonadPlus and then went on the rampage! Nothing broke. I got rid of a lot of cruft. I did make essential use of hiding instance Functor for structures which were both Applicative and Traversable. I cut tens of lines for the cost of one or two hidings.
If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful.
I'm up for that role, if that's appropriate.
I am in too many inner loops. But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98.
One thing that's really noticeable and sad about the status quo is that we can't refine the structure of a bunch of related classes without breaking established interfaces. I guess an interesting question might be what progress is effectively being blocked by our current inability to engineer around this problem. What are we stuck with just now? This is a recurring issue, at least as far as mailing list heat is concerned, but it would be good to have more evidence of substantial impact. The Monoid vs Semigroup issue is a case in point, perhaps. Folks, what do you think? Cheers Conor PS Are there any other default superclass instances for standard classes that SHE could usefully bake in? Sadly, we can't purge redundant methods from standard classes just yet, but we can at least get rid of boilerplate instances.
| > If someone felt able to act as moderator for the discussion, willing | > to summarise conclusions, open questions, and so on, on the wiki | > page, that would be enormously helpful. | | I'm up for that role, if that's appropriate. I'll take you up on that, thank you! I've added some "SLPJ note" notes to http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances which could perhaps do with clarifying. Simon PS: to avoid spam, maybe now we have advertised this thread, we should restrict it to ghc-users? The *current* library question about mappend etc can stay on libraries.
On Mon, Aug 15, 2011 at 12:36 PM, Simon Peyton-Jones
(Adding GHC users, and changing title.)
| 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... | | Nice. But will it be happening soon, or not? And how soon is | soon?
Not soon enough to be useful for this mappend question.
But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about
(a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"?
(b) What is the "right" design?
My only input is that we have at least 2-3 (depending on whether the latter two are to be considered separate) hierarchies in want of refactoring: Functor/Applicative/Monad, Num and friends, and Monoid. Ideally any solution would "solve the problem" for all of them, but even if it doesn't (and only solves, say, Monad's case), I think it should be a requirement that it at least allows for the others to be solved as well in an incremental fashion afterwards (whether by 'upgrading' the by-then existing feature, or adding a new, orthogonal one). The undesirable scenario would be where you would have to "change the world" all over again a second time to resolve the remaining problems. This is just in the abstract; my brain is too under-resourced to figure out where the proposed feature stands in relation to this. (On its own terms, I like it.)
(c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything)
With help from Conor we have made some progress on this: we have a draft design: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
If you care about the issue, maybe you can help resolve the above questions. In particular, to give concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point.
If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful. I am in too many inner loops. But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98.
Simon
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
-- Work is punishment for failing to procrastinate effectively.
My only input is that we have at least 2-3 (depending on whether the latter two are to be considered separate) hierarchies in want of refactoring: Functor/Applicative/Monad, Num and friends, and Monoid. Ideally any solution would "solve the problem" for all of them, but even if it doesn't (and only solves, say, Monad's case), I think it should be a requirement that it at least allows for the others to be solved as well in an incremental fashion afterwards (whether by 'upgrading' the by-then existing feature, or adding a new, orthogonal one). The undesirable scenario would be where you would have to "change the world" all over again a second time to resolve the remaining problems.
Another place where this might help would be with the RandomGen/SplittableGen issue: http://hackage.haskell.org/trac/ghc/ticket/4314 If "design goal 1" is met, then clients would not have to refactor their Random instance to match the new class factoring. -Ryan
participants (10)
-
Brandon Allbery -
Conor McBride -
Edward Kmett -
Gábor Lehel -
Johan Tibell -
Malcolm Wallace -
Ryan Newton -
Sebastian Fischer -
Simon Peyton-Jones -
Yitzchak Gale