Map with a different Monoid instance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Map with a different Monoid instance

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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Mario Blazevic-2
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Ryan Trinkle-3
In reply to this post by David Feuer
Hi David,

Totally agreed.  I'm not quite sure how to approach the naming issue, either - there's definitely potential for confusion, which we need to try very hard to avoid.  However, the Monoid instance for Map is certainly something I've run into many times, and newtyping Map involves a pretty huge amount of boilerplate.

I also agree about separating safe and unsafe functions.  Especially with your new combinators in Data.Map.Merge and friends, I'd like to have a straightforward way to ensure we get rid of any unsafe functions in our code.


Best,
Ryan

On Thu, May 25, 2017 at 12:55 PM, David Feuer <[hidden email]> 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.


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Michael Snoyman
In reply to this post by Mario Blazevic-2


On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Ryan Trinkle-3
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 <[hidden email]> wrote:


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



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

David Feuer
In reply to this post by Michael Snoyman
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 <[hidden email]> wrote:

>
>
> On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

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


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Ryan Trinkle-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
>
>
> On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <[hidden email]>
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

David Feuer
In reply to this post by Michael Snoyman
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>> >
>> >
>> > On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <[hidden email]>
>> > 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
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> >
>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Henning Thielemann
In reply to this post by David Feuer

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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Mario Blazevic-2
In reply to this post by David Feuer
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 <[hidden email]> wrote:
>>
>>
>> On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <[hidden email]>
>> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>


--
Mario Blazevic
[hidden email]
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

Ryan Trinkle-3
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ć <[hidden email]> 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 <[hidden email]> wrote:


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



--
Mario Blazevic
[hidden email]
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Map with a different Monoid instance

David Feuer
In reply to this post by Henning Thielemann
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
<[hidden email]> 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.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries