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.