Maximum and Minimum monoids
gabriel439 at gmail.com
Thu Dec 27 21:18:54 CET 2012
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
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.
More information about the Libraries