Proposal: Max and Min for Monoid

[wren ng thornton]

On 9/23/10 6:46 PM, Ross Paterson wrote:
> On Thu, Sep 23, 2010 at 03:08:48PM -0400, Edward Kmett wrote:
>> On the other hand, composing AddBounds introduces another element on the other
>> side, which serves as an annihilator when composed with Min and Max. This is
>> fine for some applications, but I don't believe it subsumes MinPriority and
>> MaxPriority.
>
> This extra element at the other end introduced by AddBounds bothers
> me too.  So I agree with the conclusion that we need both versions that
> add a maximum/minimum, and ones that take it from Bounded.  That leaves
> the question of which variant deserves to be called Max/Min.

For my part, I like the Min/Max being the Bounded Ord one, as in the 
monoids library.

One amendment I'd like to bring up is that I think 
PriorityMin/PriorityMax should instead be (Priority Min)/(Priority Max), 
that is, make Priority --or whatever it's called-- take Min/Max as a 
phantom type argument. This can help to simplify things once you start 
adding in other ordering variants like

     newtype Arg  Min/Max a b = Arg  (Maybe (b,a))
     newtype Args Min/Max a b = Args (Maybe (b,[a]))

etc. I'm not suggesting that these ones be added to base, but it'd be 
nice to have a uniform API for handling all the different monoids of 
ordering.

-- 
Live well,
~wren