name change proposal (EnumMap => Map, EnumSet => Set)

[jwaldmann]

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

[jwaldmann]

ping

[Mikolaj]

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

[jwaldmann]

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

[Mikolaj]

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.

[Mikolaj]

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.