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.

[andreasabel]

So the pattern I see frequently (and apply myself) is ("default culture"):

import Data.Map (Map) 
import Data.Map qualified as Map
import Data.IntMap (IntMap)
import Data.IntMap qualified as IntMap

This would not be possible if all the map types would just be called Map.

In the ML world (PL ML, not AI ML), it is common to use the carrier type of a module T, so the pattern would be:

import Data.Map qualified as Map
import Data.IntMap qualified as IntMap
type Map = Map.T
type IntMap = IntMap.T

The proposal seems to breathe this spirit.
This is fine, however, the Haskell culture went a different route.

I think staying in sync with the default culture is overall more beneficial.