Map with a different Monoid instance

[Ryan Trinkle]

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ć <mblazevic at stilo.com> 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 <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
>>>
>>>
>
> --
> Mario Blazevic
> mblazevic at 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 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/682d2f4b/attachment.html>