Map with a different Monoid instance

[David Feuer]

I think we definitely don't want a Semigroup constraint on the key.
Aside from the (potentially severe) performance issues, I think the
semantics would be pretty awful. Inserting a key-value pair could
potentially collapse a large map into a singleton!

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
>> >
>
>