>
> Most of the time when people call seq on a set or map they want to iterate
> over it, and that's fine.
Right, I guess I meant insertion order.
Though, is it not true that conceptually, two implementations of
IPersistentSet would not need to return elements in the same order? Even to
the point, that a copy of the same concrete implementation isn't even
required to do so? I understand this works given Clojure's concrete
implementation where the Hash are sorted because they're stored in a Trie,
which is ordered, but that's an implementation detail no? And is not
mandated by the contract of the interface? Where as, an IPersistentVector
must conceptually return elements in insertion order?
On Saturday, 24 February 2018 15:44:00 UTC-8, tbc++ wrote:
>
> >> If it happens to work, it is accidental, and should not be relied on.
>
> Yes, and no. The actual order may change between Clojure releases (last
> time it changed was with 1.6), or between two equal collections, but the
> ordering will not change between two calls to `seq` on the same instance of
> a hashmap or set. Therefore you absolutely can rely on this working:
> (zipmap (keys m) (vals m)), you will never get a jumbling of keys and
> values. Most of the time when people call seq on a set or map they want to
> iterate over it, and that's fine.
>
> On Sat, Feb 24, 2018 at 2:32 PM, Didier <did...@gmail.com <javascript:>>
> wrote:
>
>> is there a way round it?
>>>
>>
>> Something else I need to point out is that you really should not use a
>> Set for order. Sets are specifically unordered, and provide no guarantees
>> of order. Try calling first, second and last on #{1 2 3} for example,
>> you'll probably get things back in a different order.
>>
>> If it happens to work, it is accidental, and should not be relied on. If
>> you want order, use a Vector or a List. Vectors are probably going to feel
>> more natural, since they append to the end.
>>
>> You use a Set over a Vector most of the time, because you are
>> specifically telling the consumers of the collection not to rely on order,
>> that the order is meaningless and no logic should be derived from it.
>> Similarly, if you use a Vector over a Set it should be because the order is
>> guaranteed and does matter, and consumers of the collection are welcomed to
>> assume this and build logic that is order dependent.
>>
>> That said, yes there is a way around it, you can call persistent! to get
>> back a PersistentHashSet, and then call first on it. Going from a transient
>> to a persistent is O(1), so its really fast. You can keep alternating
>> between persistent and transient as your needs change between reading and
>> iterating back to updating.
>>
>> Reading and iterating over a persistent is just as fast, the transient
>> provides no value. Transient will only make updates and inserts faster.
>>
>> On Saturday, 24 February 2018 07:15:02 UTC-8, Alan Forrester wrote:
>>
>>> Calling (first #{1}) gives the result 1.
>>>
>>> Calling (first (transient #{1})) gives an error:
>>>
>>> “IllegalArgumentException Don't know how to create ISeq from:
>>> clojure.lang.PersistentHashSet$TransientHashSet clojure.lang.RT.seqFrom
>>> (RT.java:550)”
>>>
>>> Is this behaviour intended?
>>>
>>> And whether or not this is intentional is there a way round it?
>>>
>>> Alan Forrester
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> <javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
