if there was a guy who knew the answer, it would be @U07SQTAEM

There’s nothing as good as ganja.js for any other language, sadly. I do have a Clojure/Cljs port that I use for my own stuff, but it isn’t public and will take some time to get ready for general consumption.

thanks for the answers.

From what I know of the implementation, yes it is, for the same identical collection. For two arbitrary collections that are =, not necessarily, no.

Similar to how the implementation will return the same sequence of elements from seq for the same identical collection, but not necessarily for two different collection objects that are = to each other.

For the exceptional cases, I am thinking specifically of unordered collections here only.

There is a huge amount of code within Clojure's implementation that depends upon this property of first and rest

yeah that's why I hoped there'd be something written down about it

Similar questions have been asked before, and Alex has said that yes, such behavior is intentional and guaranteed. But I don't know if it's written anywhere e.g. on the Clojure's website or any other docs resource.

From https://clojure.org/guides/learn/hashed_colls#_keys_or_values: > While maps are unordered, there is a guarantee that keys, vals, and other functions that walk in "sequence" order will always walk a particular map instance entries in the same order.

The doc string for rest hints at it very strongly:

Returns a possibly empty seq of the items after the first. Calls seq on its
argument.

As a short counterexample for (lack of) guarantees across non-identical but = unordered collections, in case you have not encountered this before:

user=> (hash 0)
0
user=> (hash 92612215)
0
user=> (def s1 (hash-set 0 92612215))
#'user/s1
user=> (def s2 (hash-set 92612215 0))
#'user/s2
user=> s1
#{0 92612215}
user=> s2
#{92612215 0}
user=> (= s1 s2)
true
user=> (seq s1)
(0 92612215)
user=> (seq s2)
(92612215 0)
user=> (first s1)
0
user=> (rest s2)
(0)

Because the implementation of hash-map and hash-set use an ordered list of set elements / hash values for elements/keys that have equal hashes, and the order of elements in that list depends upon the order that elements were added to the hash-set/map

it's in the docstring of #'keys and vals

no need to think about impl.

the original question is malformed? > is rest guaranteed to drop the element returned by first? that's the contract of rest for all seqs

doesn't matter that it's a seq of map entries or doodads

I think the original asker was hoping for something like: "What do you take as the authoritative documentation that says that this is the contract for rest, for all seqs?"

I frame my answers a little more cautiously, given that I'm not in a position to make new authoritative documentation 🙂. (well, not without careful review anyway, which is not what Slack is about on first writing)

kind of a fun thing to run through test.check:

(s/def ::map-or-set
  (s/or
   :map map?
   :set set?))

(def first-rest-prop
  (prop/for-all [x (s/gen ::map-or-set)]
                (let [fst (first x)]
                  (every? #(not= fst %)
                          (rest x)))))

(defspec first-rest-test  first-rest-prop)

> (first-rest-test 1e5)
{:result true,
 :pass? true,
 :num-tests 100000.0,
 :time-elapsed-ms 72552,
 :seed 1721685161814}

(or (empty? x)
    (= (into (empty x) (rest x))
       (if (map? x)
         (dissoc x (-> x first key))
         (disj x (first x)))))

NaN occurrences in the randomly generated test cases?

{:shrunk
 {:total-nodes-visited 31,
  :depth 5,
  :pass? false,
  :result false,
  :result-data nil,
  :time-shrinking-ms 1,
  :smallest [{##NaN 0}]}}

NaN could be called AONEtANEI (An Object Not Equal to Anything Not Even Itself). Very weird.

or maybe even A͒́̀ǹ̕͘ ̉̕͞O̓̉́b͘͡͠j̶͆̆e͂̇̕c̶͐͘t̸̐ ̶̧͝N͘̕͜ơ̕͢t͑̓̀ ̷͑͞Ē̷̇q̵̊͊ư̅̊a̽̍̚ļ͐̆ ̧̅̕t̓̔͝o͐̀͌ ̛̾̓A̽͐͡ṅ̵͠ỳ̕tͦ̓͡h̢́i̵͌̑n̓̆͡g̸͑͝ ̢͛N̏̎̅ǫ̆̚t͛͊͠ ̀̕͝Ę̧҉v͂̓̕e̔͑͘nͦ̔̅ ̷̆̕I͛̋͝t̸̆͋s̡e͒̅̀l̸̔̓f̛͘

@U050ECB92 > the original question is malformed? >> is rest guaranteed to drop the element returned by first? > that's the contract of rest for all seqs that was my understanding but couldn't confirm by googling. I'll take this as authoritative 😄