Maximum and Minimum monoids

[Roman Cheplyaka]

* Gabriel Gonzalez <gabriel439 at gmail.com> [2012-12-27 14:31:05-0600]
> On 12/27/2012 02:25 PM, Roman Cheplyaka wrote:
> >Wouldn't it be better to have a real algebraic type instead of wrapping
> >Maybe?
> >
> >Something like
> >
> >   data Maximum a = MinusInfinity | Maximum a
> >   data Minimum a = PlusInfinity  | Minimum a
> >
> >Maximum x is more concise than Maximum (Just x), and MinusInfinity is
> >more descriptive than Maximum Nothing. getMaximum/getMinimum functions
> >can still return Maybes.
> >
> >Anyway, I'm +1 to having something along these lines.
> >
> >Roman
> >
> Interesting.  Then you can recapitulate the original Maybe API using:
> 
> getMaximum :: Maximum a -> Maybe a
> getMinimum :: Minimum a -> Maybe a
> 
> One slight disadvantage is that there might be a tiny overhead for
> converting between Maximum/Minimum and Maybe, but I doubt that would
> be a bottle-neck in any application.

But the type isn't abstract, so nothing prevents one from using direct
pattern matching in tight loops.

> Another disadvantage is then it sets a precedent for redefining the
> First and Last Monoids to similarly more descriptive types.  When I
> did it the Maybe way I was just copying the way First and Last
> worked.

I don't think the analogy holds. First and Last are wrappers for Maybe
by intention — they are needed because we can't have two different
instances for Maybe (although both of them make sense).

In this case, however, Maybe is used artificially to "lift" numbers.
Monoidal instance for Maybe corresponding to 'max' would look rather
weird.

Finally, we have nice names for mempty of Maximum/Minimum but not of
First/Last.

Roman