This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-09
Channels
- # announcements (12)
- # beginners (159)
- # boot (3)
- # calva (41)
- # cider (48)
- # clara (2)
- # clj-kondo (8)
- # cljdoc (8)
- # clojure (70)
- # clojure-dev (10)
- # clojure-europe (2)
- # clojure-losangeles (1)
- # clojure-nl (12)
- # clojure-spec (7)
- # clojure-uk (63)
- # clojurescript (24)
- # cursive (24)
- # datomic (22)
- # expound (17)
- # figwheel (1)
- # fulcro (176)
- # graphql (23)
- # jobs (9)
- # jobs-discuss (56)
- # kaocha (1)
- # mount (3)
- # nyc (1)
- # off-topic (91)
- # onyx (3)
- # overtone (4)
- # pathom (3)
- # pedestal (1)
- # re-frame (11)
- # reitit (19)
- # ring (8)
- # shadow-cljs (16)
- # test-check (5)
- # testing (2)
- # tools-deps (20)
- # vim (9)
Well, that's almost certainly way oversimplified. The rabbit hole looks rather deep. Thoughts on approach welcome.
devn What is the rabbit hole that this patch leads to?
I don't think making seq
work on transients would be a viable solution
only way to do that would be to make a full copy of the data structure, is my hasty guess
(defn empty? [c] (zero? (count c)))
works for transients
I'm not sure that suggests any good implementation though; you wouldn't want to use that on lazy collections
switching on whether it's a transient or not leads to the old "does it make normal things slower?" conundrum
the most plausible thing I can imagine is rewriting empty?
in terms of a new interface or protocol
which sounds like at least moderately sized work