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