Map with a different Monoid instance

[Ryan Trinkle]

Unbiased sounds good to me.

That's a good point, Mario.  I'm in favor of the modernization, but I don't
have a strong preference that it happen along with this other change.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170525/95db13ac/attachment-0001.html>