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