Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#1249 closed proposal (wontfix)

Data.Map.map should be deprecated/removed

Reported by: ajb@… Owned by:
Priority: normal Milestone: Not GHC
Component: libraries/base Version: 6.6
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Easy (less than 1 hour)
Test Case: Blocked By:
Blocking: Related Tickets:

Description

(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.
  1. 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.

Change History (8)

comment:1 Changed 7 years ago by duncan

  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.

Data.Map is supposed to be imported qualified. As it says in the haddock docs Data.Map is supposed to be imported qualified:

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

then you can use Map.map which now doesn't clash with anything and you don't need to change any existing stuff in your code.

If you don't like using the ugly Map.! and Map.\\ you can always use Map.lookup and Map.difference instead or if you really want those operators and not the array / list versions then you can import them unqualified and hide or qualify the array / list versions.

I don't see any problem here.

comment:2 Changed 7 years ago by guest

I guess the problem is that the module as a whole doesn't hit a sweet spot. If it's meant to be imported qualified, then the operators are horrible. If it's allowed to be imported unqualified, then the names clash. Something has to give.

The "right" answer is, of course, a well-designed Edison-like abstraction layer which makes this all go away, so perhaps this isn't the right forum for the complaint.

comment:3 Changed 7 years ago by duncan

Right. I had no idea those operators existed. I've never used them.

comment:4 Changed 7 years ago by igloo

  • Milestone set to Not GHC

comment:5 Changed 6 years ago by igloo

  • Resolution set to wontfix
  • Status changed from new to closed

This proposal seems to be abandoned

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple

comment:8 Changed 4 years ago by simonmar

  • Difficulty changed from Easy (1 hr) to Easy (less than 1 hour)
Note: See TracTickets for help on using tickets.