Map with a different Monoid instance

[Ryan Trinkle]

I tend to avoid Map.union and the other biased combining functions, simply
because they seem a bit too easy for someone to accidentally come along
later and exchange the order by accident.  On the other hand, having
Map.insert use a Monoid instance seems like it would be quite unwieldy.

On Thu, May 25, 2017 at 4:37 PM, Michael Snoyman <michael at snoyman.com>
wrote:

> That's a really good question, and could theoretically even generalize
> more than that: should `insert` have a `Monoid` or `Semigroup` constraint
> on the key as well? Should this API explicitly avoid any form of throwing
> away values, and insist that, if that's the behavior you want, you do
> something like `insertWith const`?
>
> I think my guess is in line with yours, that the rest of the API functions
> should continue with the discard behavior of the current API, but it's
> worth at least raising the question.
>
> On Thu, May 25, 2017 at 2:08 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> Unbiased sounds nice, but I'm a bit concerned that it might suggest
>> bigger differences than just the Monoid instance. I assume people
>> still want the same left-biased union function.
>>
>> On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman <michael at snoyman.com>
>> wrote:
>> >
>> >
>> > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <mblazevic at stilo.com>
>> > wrote:
>> >>
>> >> On 2017-05-25 12:55 PM, David Feuer wrote:
>> >>>
>> >>> A lot of people have wrappers around Data.Map and Data.IntMap to give
>> >>> them more useful (Semigroup and) Monoid instances. I'd like to add
>> such
>> >>> wrappers to containers. What we need to be able to do that are
>> *names* for
>> >>> the new modules. I can't think of any, so I'm reaching out to the
>> list.
>> >>> Please suggest names!
>> >>
>> >>
>> >> Data.Map.Monoidal is not strictly correct but would give a pretty good
>> >> idea at first glance.
>> >>
>> >> Data.Map.Symmetric would be more correct, since its Semigroup and
>> Monoid
>> >> instances would be symmetric, with no preference for the left argument
>> as
>> >> currently.
>> >>
>> >>
>> >
>> > Just to throw out an option here: Unbiased. I don't feel strongly about
>> it,
>> > but thought throwing it out may be helpful.
>> >
>> >>>
>> >>> Another question is whether we should take the opportunity of new
>> modules
>> >>> to modernize and streamline the API a bit. I'd like, at least, to
>> separate
>> >>> "safe" from "unsafe" functions, putting the unsafe ones in .Unsafe
>> modules.
>> >>
>> >>
>> >>         I think it would be better to keep the API exactly the same,
>> much
>> >> like Data.Map.Strict does. I don't want to think about the incidental
>> API
>> >> differences when I switch from one module to another. If you're going
>> to
>> >> modernize, modernize all the modules at once. That's what version
>> numbers
>> >> are for.
>> >
>> >
>> > +1. I'd also argue against changing the API right now.
>> >
>> > Michael
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170525/3195da11/attachment.html>