If you want a more uniform factoring, then at the risk of further exploding the number of options under consideration, there is an obvious choice: class Semigroup s where sappend :: s -> s -> s -- ^ like how Functor m => Monoid m, you get the obvious 'spiritual but unenforced' Semigroup m => Monoid m newtype Min a = Min a deriving (Eq,Ord,Data,Typeable) instance Ord a => Semigroup (Min a) where Min a `sappend` Min b = Min (a `min` b) instance (Ord a, Bounded a) => Monoid (Min a) where mempty = maxBound mappend = sappend newtype Max a = Max a deriving (Eq,Ord,Data,Typeable) instance Ord a => Semigroup (Max a) where Max a `sappend` Max b = Max (a `max` b) instance (Ord a, Bounded a) => Monoid (Max a) where mempty = minBound mappend = sappend data Unital m = Unit | Semi m deriving (Eq, Data, Typeable) instance Semigroup s => Semigroup (Unital s) Unit `mappend` b = b a `mappend` Unit = a Semi a `mappend` Semi b = Semi (a `sappend` b) instance (Semigroup s) => Monoid (Unital s) where mempty = Unit mappend = sappend With that Min a, Max a, Unital (Min a), Unital (Max b) would all work, and you'd pick up a type that plays the role that the Maybe monoid purports to play, which is the trivial lifting of a semigroup into a monoid by adding an additional unit. A real proposal would probably want to flesh Unital out with a couple more combinators like -- 'maybe' unital :: a -> (m -> a) -> Unital m -> a unital z _ Unit = z unital _ f (Semi a) = f a The only real consequence other than trying to figure out where Semigroup would fit, and fighting the 'added complexity' battle: * MinPriority and MaxPriority can be smart enough to provide a correct Ord instance for the composite. The 'factored' version cannot without other chicanery. Given a blank slate, this would be my favorite option. -Edward On Fri, Sep 24, 2010 at 3:50 AM, wren ng thornton < wren@community.haskell.org> wrote:
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
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries