Re: Maximum and Minimum monoids
I'm still not convinced by the Bounded instance for Maybe, which seems like a hack. I would prefer to just use the Monoid instance for "Maybe (Max a)" and just fmap "getMaximum" over the result rather than pretend that Maybe is Bounded when it's not. 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. 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? I still believe that the correct answer for "minimum []" should be Nothing or a similar type with a distinguished infinity like those that Roman proposed.``
Personally I like having both Maximum-and-Minimum-with-sentinel version
like the proposed Maximum and Minimum here, along with the simpler Max and
Min semigroups that upgrade themselves to a Monoid when Bounded is present.
Each is useful for different usecases. I like having access to the
efficient version whenever I know the target admits a minimum value (like
Int).
Paying for unnecessary Maybe's makes me cry.
-Edward
On Fri, Dec 28, 2012 at 4:39 PM, Gabriel Gonzalez
I'm still not convinced by the Bounded instance for Maybe, which seems like a hack. I would prefer to just use the Monoid instance for "Maybe (Max a)" and just fmap "getMaximum" over the result rather than pretend that Maybe is Bounded when it's not.
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.
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? I still believe that the correct answer for "minimum []" should be Nothing or a similar type with a distinguished infinity like those that Roman proposed.``
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries
On 12/28/2012 05:18 PM, Edward Kmett wrote:
Personally I like having both Maximum-and-Minimum-with-sentinel version like the proposed Maximum and Minimum here, along with the simpler Max and Min semigroups that upgrade themselves to a Monoid when Bounded is present.
Each is useful for different usecases. I like having access to the efficient version whenever I know the target admits a minimum value (like Int).
Paying for unnecessary Maybe's makes me cry.
-Edward
That sounds like a reasonable compromise. I can buy the efficiency argument.
On Fri, Dec 28, 2012 at 11:39 PM, Gabriel Gonzalez
I'm still not convinced by the Bounded instance for Maybe, which seems like a hack. I would prefer to just use the Monoid instance for "Maybe (Max a)" and just fmap "getMaximum" over the result rather than pretend that Maybe is Bounded when it's not.
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.
Since I'm the one who initially mentioned the Bounded approach, let me say: I agree with this reasoning. It made sense in my specific case, but in general I don't think it's a good idea. Do we really want to make it impossible to use Max and Min with Integers? Michael
participants (3)
-
Edward Kmett -
Gabriel Gonzalez -
Michael Snoyman