Open jwaldmann opened 9 years ago
ping
Hi! I'm your new maintainer. :)
I'm not strongly opposed, but I imagine some people may import the type not qualified. I don't understand the comment about HashMap
. The type is not called Map
in https://hackage.haskell.org/package/unordered-containers-0.2.9.0/docs/Data-HashMap-Lazy.html
Hi.
Yes, same thing - Data.HashMap should define a type named Map
-
so we can switch implementations (hashtable, search tree, patricia tree) by just switching an import.
Possibly this can be done via backpack in the future ( https://ghc.haskell.org/trac/ghc/wiki/Backpack )
It's not exactly high priority, as I can use a work-around mentioned here https://mail.haskell.org/pipermail/haskell-cafe/2018-September/129940.html (switching via type classes).
Interesting. As long as backward compatibility is preserved, feel free to experiment. This package is not particularly fragile or complex, so a few type synonyms, or something more, won't hurt.
Now that I think about, it we'd probably want to follow IntMap
. That is, as soon as IntMap provides a Map
alias for its type, I'd gladly follow suit. However, before that, it would be confusing, suggesting that EnumMap
shares the constrain requirements of Map
, while it's between Map
and IntMap
. Also, it's performance is that of the latter, not the former.
The name (EnumMap) seems wrong, though. The module will be imported qualified anyways, so the type should just be Map. Then, changing the implementation (if the key type implements Ord, Enum, and Hashable) is really just changing the import. But then, it's at least consistently wrong - e.g., in line with Data.HashMap.
see also discussion in this thread: https://mail.haskell.org/pipermail/haskell-cafe/2015-March/118897.html