Re: Map with a different Monoid instance

There's also some nice interplay here with 'coerce', namely that by coercing NewMap k v to Map k (Data.Semigroup.First v), we can recover the original behavior. On Thu, May 25, 2017 at 6:10 PM, Mario Blažević wrote:

On 2017-05-25 04:08 PM, David Feuer 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.

I agree. Quite apart from the compatibility issues, I'd rather use mappend or (<>) once the instances are fixed than any union function, biased or not.

...

On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman wrote:

...

On Thu, May 25, 2017 at 11:38 AM, Mario Blažević 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Mario Blazevic mblazevic@stilo.com Stilo International

This message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, copying, or distribution is strictly prohibited. If you are not the intended recipient(s) please contact the sender by reply email and destroy all copies of the original message and any attachments.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries