Map with a different Monoid instance

David Feuer david.feuer at gmail.com
Thu May 25 23:22:19 UTC 2017


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
<lemming at henning-thielemann.de> 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.


More information about the Libraries mailing list