Proposal: Max and Min for Monoid
conal at conal.net
Thu Sep 23 20:27:36 EDT 2010
On Thu, Sep 23, 2010 at 4:46 PM, Edward Kmett <ekmett at gmail.com> wrote:
> 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.
> On Sep 23, 2010, at 7:20 PM, Conal Elliott <conal at conal.net> 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 at soi.city.ac.uk>
> ross at 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
>> > 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
>> > 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 at haskell.org>Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries