
On Thu, Sep 23, 2010 at 4:46 PM, Edward Kmett
The biggest problem with splitting AddBounds is that the result is then not able to be Bounded as it only supplies one bound.
Right. It would take both applications to be in Bounded.
This defeats the purpose of constructing it, because now it cannot be composed with Min/Max.
Yeah. For using in Min/Max we'd have to have Bounded, which is overkill, or a decomposition of Bounded, which probably makes more sense anyway but has the usual backward-compat issues.
-Edward
On Sep 23, 2010, at 7:20 PM, Conal Elliott
wrote: That extra bit bothered me, too. One could split AddBound into AddMax and AddMin. Perhaps better is to fix the problem upstream, splitting Bounded into WithMin and WithMax.
On Thu, Sep 23, 2010 at 3:46 PM, Ross Paterson <
ross@soi.city.ac.uk> 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. _______________________________________________ Libraries mailing list
Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries