Map with a different Monoid instance

older
Re: Map with a different Monoid...

David Feuer

25 May 2017 25 May '17

12:55 p.m.

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

Attachments:

attachment.html (text/html — 594 bytes)

Show replies by date

Mario Blažević

25 May 25 May

1:38 p.m.

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.

...

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.

Michael Snoyman

3:43 p.m.

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

Ryan Trinkle

3:46 p.m.

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

David Feuer

4:08 p.m.

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

Michael Snoyman

4:37 p.m.

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

Ryan Trinkle

5:01 p.m.

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

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

such 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

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

David Feuer

5:57 p.m.

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 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 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 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 Blažević

6:10 p.m.

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.

Ryan Trinkle

6:31 p.m.

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

Henning Thielemann

6 p.m.

On Thu, 25 May 2017, 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! 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.

There are a lot notions of "unsafe", some mean "partial" others mean "breaks abstraction" others mean "can do IO although type signature promises not to do so". I think we should stick to the notion of "safe" as in "unsafePerformIO" and "SafeHaskell". In this respect all functions in Data.Map are safe, aren't they? Functions that may break abstraction can be exported by "Internal" modules - which already exist.

David Feuer

7:22 p.m.

Yes, all of these should be safe from a SafeHaskell perspective (if they're not, that's a bug!). I would like to remove abstraction-breaking functions from the primary modules (or at least refrain from introducing them into new map-with-different-monoid modules), and put them in .Unsafe modules. While I think users should generally avoid using partial functions, they don't have nearly as much potential to confuse the heck out of someone downstream from them as, say, a Map whose keys are duplicated or out of order. Internal modules serve a different purpose: their APIs are intentionally allowed to be completely unstable, but people willing to put up with that can implement "low-level" operations the library does not itself support as efficiently. A .Unsafe module would be subject to the PVP and follow a conservative deprecation policy; a .Internal module would not. On Thu, May 25, 2017 at 6:00 PM, Henning Thielemann wrote:

...

On Thu, 25 May 2017, 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! 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.

There are a lot notions of "unsafe", some mean "partial" others mean "breaks abstraction" others mean "can do IO although type signature promises not to do so". I think we should stick to the notion of "safe" as in "unsafePerformIO" and "SafeHaskell". In this respect all functions in Data.Map are safe, aren't they? Functions that may break abstraction can be exported by "Internal" modules - which already exist.

2919

Age (days ago)

2919

Last active (days ago)

List overview

Download

11 comments

5 participants

participants (5)

David Feuer
Henning Thielemann
Mario Blažević
Michael Snoyman
Ryan Trinkle