Maximum and Minimum monoids

[Gabriel Gonzalez]

On 12/27/2012 02:02 PM, Greg Fitzgerald wrote:
> > It made sense in my specific use case, but I think Gabriel's version 
> is better as the general approach.
>
> Can Gabriel derive his version from Michael's with:
>
> instance Bounded (Maybe a) where
>   maxBound = Nothing
>   minBound = Nothing
>
> The Bounded constraint seems right to me.  If Bounded doesn't apply to 
> your datatype, maybe a Semigroup would be more appropriate than a Monoid?
>

In principle the two approaches are equivalent, but I can think of some 
"touchy feely" differences, though.

The first is that while the Bounded approach you propose does 
recapitulate my approach in theory, in practice it encourages people to 
use minBound (without the Maybe) as the default way to fold values.  The 
problem with using a non-Maybe minBound as the default is:

* It loses information (because you can't tell the difference between 
"minimum []" and "minimum [minBound, ...]"

* It gives a weird result on empty lists.  "minimimum [] = minBound" 
feels a little weird.

* It requires implementing "Bounded" for the type in question, when 
really an "Ord" constraint is enough to do maximums and minimums.

Also, you can recapitulate the Bounded approach with my approach by 
using "fromMaybe minBound"/"fromMaybe maxBound".

The next issue is whether it will be obvious to users that Maybe is a 
bounded type.  You would need to document that so that users know to use 
that trick and that only works if users read the haddocks. If they study 
the type in ghci, for example, or any context other than the haddocks 
they will lose that key piece of information.

More philosophically, it's not clear why that Maybe instance for Bounded 
makes any sense.  It seems like a workaround, rather than a natural 
solution.

Also, it's not clear why something needs to be bounded to have a 
maximum.  Real numbers are unbounded, yet you can still take a maximum 
of a set of real numbers.