Re: [Haskell-cafe] Proposal #3339: Add (+>) as a synonym for mappend
On Sun, Aug 14, 2011 at 13:38, Yitzchak Gale
Brandon Allbery wrote:
Umm, I think the semigroups package will break everything that creates Monoid instances anyway.
It has never broken anything for me. What do you mean?
Anything useful has to be modified to depend on SemiGroup as well to get mconcat or its replacement; that's why you jumped the proposal to begin with.... As others have noted, this is a rather intrusive change to the Haskell ecosystem. *If* it has in fact been decided to go ahead with it, *then* this proposal should be merged with yours since the best time to do it is when mconcat is being relocated anyway. I don't think we've made it past the "if", especially given the comments so far. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms
Brandon Allbery wrote:
Anything useful has to be modified to depend on SemiGroup as well to get mconcat or its replacement; that's why you jumped the proposal to begin with....
Not at all. Types with Monoid instances need an additional instance, a Semgroup instance, in order to be able to use '<>' instead of mappend. mconcat is not involved in this discussion. That is the current situation. I am advocating leaving it that way.
As others have noted, this is a rather intrusive change to the Haskell ecosystem.
Exporting <> from Data.Monoid is the intrusive change. I am strongly against it. In the long run, it will create ugliness and inconvenience to our class system, which has enough problems as it is. I advocate leaving things as they are. If individual library authors wish to add a Semigroup instance to their Monoid instances as a convenience, which is harmless, I think that would be wonderful. But that is a separate issue. Thanks, Yitz
On Sun, 2011-08-14 at 21:05 +0300, Yitzchak Gale wrote:
Brandon Allbery wrote:
Anything useful has to be modified to depend on SemiGroup as well to get mconcat or its replacement; that's why you jumped the proposal to begin with....
Not at all. Types with Monoid instances need an additional instance, a Semgroup instance
That does require depending on semigroups though, and I think that's what Brandon was saying. Of course, the obvious solution to this would be to promote semigroups, e.g., by adding it to the Haskell Platform or including it in base... but the current semigroups package is a bit heavyweight for that; it exports four new modules for what is really a very simple concept! -- Chris Smith
I originally didn't have the package exporting those things.
I would be amenable to standardization without them, but I use them in about
20 packages that are built on top of semigroups, and naturals and non-empty
lists come up when talking about semigroups a lot.
Rather than having them live way up in extension land with the rest of my
algebra libraries i moved them down to where they could do some good and
admit some optimizations.
On Sun, Aug 14, 2011 at 2:21 PM, Chris Smith
On Sun, 2011-08-14 at 21:05 +0300, Yitzchak Gale wrote:
Brandon Allbery wrote:
Anything useful has to be modified to depend on SemiGroup as well to get mconcat or its replacement; that's why you jumped the proposal to begin with....
Not at all. Types with Monoid instances need an additional instance, a Semgroup instance
That does require depending on semigroups though, and I think that's what Brandon was saying.
Of course, the obvious solution to this would be to promote semigroups, e.g., by adding it to the Haskell Platform or including it in base... but the current semigroups package is a bit heavyweight for that; it exports four new modules for what is really a very simple concept!
-- Chris Smith
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Brandon Allbery -
Chris Smith -
Edward Kmett -
Yitzchak Gale