Maximum and Minimum monoids

[Edward Kmett]

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 <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
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121228/44359bed/attachment.htm>