#1249: Data.Map.map should be deprecated/removed
--------------------------------+-------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: proposal | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 6.6
Severity: minor | Keywords:
Difficulty: Easy (1 hr) | Testcase:
Architecture: Multiple | Os: Multiple
--------------------------------+-------------------------------------------
(Note: Every claim here referring to Data.Map.map applies equally well to
Data.IntMap.map.)
I believe that Data.Map.map is a misfeature and should be deprecated or
removed.
1. Its name clashes with an extremely commonly-used Prelude function.
This makes the first import of Data.Map into an existing module very
expensive. Either all existing instances of "map" need to be qualified,
or the import of Data.Map needs to be qualified (which works, but makes
(!) and (\\) unnecessarily inelegant), or the import must hide map.
2. There is an easy way to get at the functionality which is already
implemented: use fmap.
Data.Set.map and Data.IntSet.map have similar problems, however you can't
just "use fmap" in that case. I don't have a good solution except to
rename these.
Data.Map.null also clashes with the Prelude, and should be reconsidered.
However, again, there isn't a simple workaround, and there are many more
overloadings of null (e.g. Data.ByteString). It's also likely that null
is used far less than map, so the cost of a clash is much lower.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1249>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
