Re: possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

2011-05-13 Thread Steve Miner
Using the array-map sounds like a good work-around when you know there are potential key collisions. It would also allow you to swap keys reliably using a temporary key. (rename-keys {:a 1 :b 2 :c 3} (array-map :a :tmp :b :a :tmp :b)) ;; {:b 1, :a 2, :c 3} The larger question is: Should

Re: possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

2011-05-11 Thread Armando Blancas
(clojure.set/rename-keys {1 :a 2 :b 3 :c}  {1 2 2 3 3 4}) returns {4 :a} That's caused by the collision between new and existing keys. Renaming 1 to 2 blows [2 :b]: {2 :a, 3 :c}; then renaming 2 to 3 blows [3 :c], leaving {3 :a}; and the last just renames 3 to 4: {4 :a}. -- You received

Re: possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

2011-05-11 Thread Armando Blancas
This renames keys to avoid collisions, using an array map to preserve the order of the keys: user= (rename-keys {1 :a 2 :b 3 :c} (array-map 3 4 2 3 1 2)) {2 :a, 3 :b, 4 :c} On May 11, 7:22 am, Armando Blancas armando_blan...@yahoo.com wrote: (clojure.set/rename-keys {1 :a 2 :b 3 :c}  {1 2 2 3

possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

2011-05-10 Thread Sunil S Nandihalli
Hello everybody, I tried to use clojure.set/rename-keys .. I kind of felt it has a little odd behaviour... for example .. (clojure.set/rename-keys {1 :a 2 :b 3 :c} {1 2 2 3 3 4}) returns {4 :a} I think a more reasonable behavior would be to have it return {2 :a 3 :b 4 :c} a further

Re: possibly non-intuitive behaviour of clojure.set/rename-keys and possible enhancement suggestion

2011-05-10 Thread Sunil S Nandihalli
I agree there are going to be problems with implementation as-well .. for example if not all the keys in the current map are not in the kmap ... but situation can be handled however, if we passed a function this is going to be harder .. .. On Wed, May 11, 2011 at 8:26 AM, Sunil S Nandihalli