Maximum and Minimum monoids
ekmett at gmail.com
Sat Dec 29 00:18:54 CET 2012
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
Paying for unnecessary Maybe's makes me cry.
On Fri, Dec 28, 2012 at 4:39 PM, Gabriel Gonzalez <gabriel439 at gmail.com>wrote:
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries