Re: map literals, computed keys and side-effects

2009-02-17 Thread Timothy Pratley
Thanks Steve, > returns a PersistentArrayMap if there are 8 entries or fewer and a   > PersistentHashMap otherwise. Ah that makes sense. Thanks for the explination. "The two (swap! a inc) forms are added to the map at read-time - which is before they are evaluated." What's the reason for this?

Re: map literals, computed keys and side-effects

2009-02-17 Thread Stephen C. Gilardi
On Feb 17, 2009, at 6:24 PM, Timothy Pratley wrote: What governs which class {} will return? The number of arguments? Yes. The current implementation of Clojure's literal map reader returns a PersistentArrayMap if there are 8 entries or fewer and a PersistentHashMap otherwise. --Steve

Re: map literals, computed keys and side-effects

2009-02-17 Thread Timothy Pratley
I don't understand your example: > user=> (class {1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9}) > clojure.lang.PersistentHashMap > user=> (class {1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8}) > clojure.lang.PersistentArrayMap What governs which class {} will return? The number of arguments? --~--~-~--~

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christian Vest Hansen
On Tue, Feb 17, 2009 at 10:07 PM, Rich Hickey wrote: > > > > On Feb 17, 3:30 pm, Christian Vest Hansen > Please don't create issues without getting a nod from me here first. Ok. I won't. I must have overlooked the "Similarly, please confirm a bug before making an entry." part. > > These are bu

Re: map literals, computed keys and side-effects

2009-02-17 Thread Rich Hickey
On Feb 17, 3:30 pm, Christian Vest Hansen wrote: > On Tue, Feb 17, 2009 at 9:08 PM, Christophe Grand > wrote: > > > Fixing array-map would make the two tests consistent but I'm not sure > > that (let [a (atom 0)] {(swap! a inc) 1 (swap! a inc) 2 }) should > > evaluate to {1 2}. > > That would

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christian Vest Hansen
On Tue, Feb 17, 2009 at 9:08 PM, Christophe Grand wrote: > > Fixing array-map would make the two tests consistent but I'm not sure > that (let [a (atom 0)] {(swap! a inc) 1 (swap! a inc) 2 }) should > evaluate to {1 2}. That would make it two distinct issues, as I see it. One for array-map, and

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christophe Grand
Christian Vest Hansen a écrit : > Just to clarify; I think PersistentArrayMap is too naïve: > > user=> {1 1 1 1 1 1 2 2} > {1 1, 1 1, 1 1, 2 2} > > Also, this is rev 1286 (just prior to lazy-branch merge thingy). > Fixing array-map would make the two tests consistent but I'm not sure that (le

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christian Vest Hansen
Just to clarify; I think PersistentArrayMap is too naïve: user=> {1 1 1 1 1 1 2 2} {1 1, 1 1, 1 1, 2 2} Also, this is rev 1286 (just prior to lazy-branch merge thingy). On Tue, Feb 17, 2009 at 8:50 PM, Christian Vest Hansen wrote: > I think I got it :) > > The two (swap! a inc) forms are added

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christian Vest Hansen
I think I got it :) The two (swap! a inc) forms are added to the map at read-time - which is before they are evaluated. However, since we are associating the (swap! a inc) key with a value twice, only the last one counts. So the atom is inc'ed to 1 once (because keys can only be in the map once),

Re: map literals, computed keys and side-effects

2009-02-17 Thread Christian Vest Hansen
That's odd. Might you have uncovered a bug regarding: user=> (class {1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9}) clojure.lang.PersistentHashMap user=> (class {1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8}) clojure.lang.PersistentArrayMap While with the atom code we have: user=> (class (let [a (atom 0)] {(swap! a