Re: Maximum and Minimum monoids

Gabriel Gonzalez

28 Dec 2012 28 Dec '12

4:32 p.m.

I am definitely in favor of adding "semigroups" to the platform if drops the containers dependency. Optionally, we could then fix the Monoid instance for Maybe so that it has a proper semigroup context and we wouldn't have to use the Option type. I would be happy with that solution. However, if we do that then rename the types to "Max" and "Min" instead of "Maximum and "Minimum", since "Maybe (Max a)" is long enough as it is.

Show replies by date

Edward Kmett

28 Dec 28 Dec

5:37 p.m.

New subject: Maximum and Minimum monoids

semigroups isn't going to drop the containers dependency. There is no other place for those instances to live and containers is farther down in the 'onion' of packages since it goes out with GHC, so this dependency cannot be inverted by the downstream and orphans here are unacceptable. -Edward On Fri, Dec 28, 2012 at 11:32 AM, Gabriel Gonzalez wrote:

...

I am definitely in favor of adding "semigroups" to the platform if drops the containers dependency. Optionally, we could then fix the Monoid instance for Maybe so that it has a proper semigroup context and we wouldn't have to use the Option type. I would be happy with that solution. However, if we do that then rename the types to "Max" and "Min" instead of "Maximum and "Minimum", since "Maybe (Max a)" is long enough as it is.

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Gabriel Gonzalez

5:38 p.m.

New subject: Maximum and Minimum monoids

On 12/28/2012 11:37 AM, Edward Kmett wrote:

...

semigroups isn't going to drop the containers dependency.

There is no other place for those instances to live and containers is farther down in the 'onion' of packages since it goes out with GHC, so this dependency cannot be inverted by the downstream and orphans here are unacceptable.

-Edward

Oh yeah, I forgot that containers ships with GHC. Then it's fine as is.

Roman Cheplyaka

6:07 p.m.

New subject: Maximum and Minimum monoids

* Gabriel Gonzalez [2012-12-28 10:32:23-0600]

...

I am definitely in favor of adding "semigroups" to the platform if drops the containers dependency. Optionally, we could then fix the Monoid instance for Maybe so that it has a proper semigroup context and we wouldn't have to use the Option type. I would be happy with that solution. However, if we do that then rename the types to "Max" and "Min" instead of "Maximum and "Minimum", since "Maybe (Max a)" is long enough as it is.

1. Actually, Max and Min are already there. No need to rename or do anything. 2. The problem isn't that semigroups is not in the platform. The problems are: 1. base already defines a (bad) Monoid instance for Maybe. We'll need to ditch it (and possibly break some code by doing that). 2. Both Monoid and Maybe are defined in base, while Semigroup isn't. So, such an instance will be orphaned. So, the best solution seems to be to merge semigroups into base. My proposal would be to move only Data.Semigroup to base, as it will lead to significant simplification, but leave other modules (NonEmpty, Natural) in a separate package, since they are of limited applicability and would gain nothing by being inside base. Roman

Gabriel Gonzalez

6:14 p.m.

New subject: Maximum and Minimum monoids

On 12/28/2012 12:07 PM, Roman Cheplyaka wrote:

...

So, the best solution seems to be to merge semigroups into base. My proposal would be to move only Data.Semigroup to base, as it will lead to significant simplification, but leave other modules (NonEmpty, Natural) in a separate package, since they are of limited applicability and would gain nothing by being inside base.

I'm okay with this. However, his Semigroup class depends on NonEmpty and Whole from the other semigroup modules, but I assume those are just there for efficiency purposes. Also, if semigroups is in base, then you can move the semigroups instances back to containers.

Edward Kmett

6:38 p.m.

New subject: Maximum and Minimum monoids

If it moved semigroups into base, and fix that god-awful Maybe Monoid instance, I'd be willing to shed the times1p function or convert it to Integral. To merely move it into the platform, I'd be more hesitant. On Fri, Dec 28, 2012 at 1:14 PM, Gabriel Gonzalez wrote:

...

On 12/28/2012 12:07 PM, Roman Cheplyaka wrote:

...
So, the best solution seems to be to merge semigroups into base. My proposal would be to move only Data.Semigroup to base, as it will lead to significant simplification, but leave other modules (NonEmpty, Natural) in a separate package, since they are of limited applicability and would gain nothing by being inside base.

I'm okay with this. However, his Semigroup class depends on NonEmpty and Whole from the other semigroup modules, but I assume those are just there for efficiency purposes.

Also, if semigroups is in base, then you can move the semigroups instances back to containers.

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Strake

7:57 p.m.

New subject: Maximum and Minimum monoids

On 28/12/2012, Roman Cheplyaka wrote:

...

1. Actually, Max and Min are already there. No need to rename or do anything.

...

So, the best solution seems to be to merge semigroups into base. My proposal would be to move only Data.Semigroup to base, as it will lead to significant simplification, but leave other modules (NonEmpty, Natural) in a separate package, since they are of limited applicability and would gain nothing by being inside base.

Agree. If we do so, we can thus define these: instance (Ord a, Bounded a) => Monoid (Max a) instance (Ord a, Bounded a) => Monoid (Min a) no Maybe wrapper needed, and "Max" and "Min" are brief.

Edward Kmett

9:11 p.m.

New subject: Maximum and Minimum monoids

And they are already present in the semigroups package with those names and that Monoid. On Fri, Dec 28, 2012 at 2:57 PM, Strake wrote:

...

On 28/12/2012, Roman Cheplyaka wrote:

...
1. Actually, Max and Min are already there. No need to rename or do anything.

...

So, the best solution seems to be to merge semigroups into base. My proposal would be to move only Data.Semigroup to base, as it will lead to significant simplification, but leave other modules (NonEmpty, Natural) in a separate package, since they are of limited applicability and would gain nothing by being inside base.

Agree. If we do so, we can thus define these:

instance (Ord a, Bounded a) => Monoid (Max a) instance (Ord a, Bounded a) => Monoid (Min a)

no Maybe wrapper needed, and "Max" and "Min" are brief.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Strake

11:50 p.m.

New subject: Maximum and Minimum monoids

On 28/12/2012, Edward Kmett wrote:

...

And they are already present in the semigroups package with those names and that Monoid.

Ah, sorry, missed the Monoid instance. On 28/12/2012, Gabriel Gonzalez wrote:

...

Moreover, the entire Bounded constraint seems wrong in principle. There is no intuitive reason why some type should be bounded to be able to take a maximum of a set of elements. The Ord constraint should be sufficient to define a maximum.

No; the set may be empty.

...

I also don't think it is a good idea to have direct Monoid instances for Max and Min, because they behave weirdly on empty lists. Do you really think that "minimum [] :: Int" should be defined?

If we had the Bounded constraint, it wouldn't be.

Strake

11:52 p.m.

New subject: Maximum and Minimum monoids

On 28/12/2012, Strake wrote:

...

...
I also don't think it is a good idea to have direct Monoid instances for Max and Min, because they behave weirdly on empty lists. Do you really think that "minimum [] :: Int" should be defined?

If we had the Bounded constraint, it wouldn't be.

Derp. Sorry, I was thinking Integer. Well, it's bounded, so yes, it should be. Now we have an exception.

4660

Age (days ago)

4660

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Edward Kmett
Gabriel Gonzalez
Roman Cheplyaka
Strake