rename-keys is hard to find when it lives in the clojure.set namespace, because it acts on maps and not sets. To my eyes set/rename-keys also looks strange when reading code, but this is the preferred way to bring in the clojure.set namespace.
This is one of the minor warts I'd like to see fixed in clojure 2.0.
> We will not delete/move existing vars as this would break existing programs.
This issue can be addressed without deletion as per Gordon's suggestion:
A new var could be added to clojure.core named clojure.core/rename-keys. Then the rename-keys var in clojure.set can be defined as:
I am aware of that, which is why I did not close the issue. I was just stating one possible resolution that is off the table.
Out of curiosity - does anyone know how/why those functions ended up in the `clojure.set` namespace?
P.S. If someone decides to alias things between namespaces I'd suggest creating a `clojure.map` ns over pouring more stuff into core.
a more accurate name for clojure.set based on its contents would be something like clojure.relational-algebra, where it defines something like relational algebra over sets of maps instead of over sets of tuples. A common operation in that case is renaming keys in maps (similar to using AS in a sql query). Which explains why rename-keys is in clojure.set
Bozhidar - only a guess, not knowledge. Relations are sets of records/tuples, so to me it makes some sense that functions on relations are in clojure.set. rename-keys is probably there because it is used by two of the functions operating on relations.