This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (9)
- # bangalore-clj (1)
- # beginners (115)
- # cider (16)
- # clara (20)
- # cljs-dev (47)
- # cljsrn (55)
- # clojure (67)
- # clojure-dusseldorf (2)
- # clojure-italy (16)
- # clojure-sanfrancisco (10)
- # clojure-spec (8)
- # clojure-uk (38)
- # clojurescript (133)
- # cursive (21)
- # datomic (36)
- # dirac (53)
- # fulcro (41)
- # graphql (6)
- # hoplon (96)
- # jobs (4)
- # juxt (2)
- # keechma (2)
- # leiningen (5)
- # off-topic (6)
- # om (2)
- # om-next (3)
- # parinfer (3)
- # re-frame (17)
- # remote-jobs (1)
- # shadow-cljs (57)
- # specter (12)
- # sql (43)
- # unrepl (10)
- # yada (5)
Hi @mfikes & @darwin I had a question..what is the scope of the
cljs-oss organization on GitHub? There is one tiny tiny cljs project that deserves some love and I was wondering whether it would be a good idea to "share" it under an :umbrella: org :smile:
@richiardiandrea Here is the discussion that led to the creation of that organization: https://clojurians-log.clojureverse.org/cljs-dev/2017-07-05.html
mfikes posted a message in the last week or so on a single 'clj' command line to start a cljs repl. Does anyone have that handy? I thought I could find it by searching on Slack, but either it has fallen out of the history, or I am just not choosing the right search terms. Anyone have that handy?
@andy.fingerhut I believe it might be this tweet: https://twitter.com/mfikes/status/955957557184614401
empty were defined as
it would seem to more closely match the semantics of Clojure's
(defn empty [coll] (when (implements? IEmptyableCollection coll) (-empty coll)))
empty(with a simple example being the case of passing a non-collection:
(empty "abc")). Is my thinking flawed here? (Apart from perf implications.)
@mfikes There are def a few people out there extending native types for
-empty and this would break it.
@mfikes Yeah, or how we often do it: First check for implements, then dispatch with
^not-native hint and then check for statisfies and dispatch to protocol dispatcher.
I guess we currently throw whereas Clojure silently return nil. So yeah, we do have a semnatic mismatch here.
I could see an argument that
empty only takes collections, but, with no spec for
empty, it is tempting to derive the semantics from the Clojure implementation.
the reason why records and map entries don’t work with empty is because they are fixed size tuples and it does not make sense to have a fixed size tuple that has 0 entries/elements
we don’t have explicit tuple types in Clojure, which is what makes this harder to talk about. Rich went down that road back in the 1.7-ish timeframe but ultimately found that it did not perform well enough to replace small vector usage (mostly due to megamorphic de-optimizations)
empty return nil as the fallback is the current documented behavior, I would find it difficult to defend that design decision. It’s hard for me to come up with a scenario where that seems like the right answer. :)
records throw UnsupportedOperationException if you try to
empty them and that seems better
I agree, I think the current impl which throws is better than silently returning
nil, even if it's different to CLJ.
I wonder, does
(empty "abc") only work accidentally in Clojure? In other words, is it an invalid program with undefined semantics?
in this case, it says “, or nil” which implies to me that it is intentionally returning nil for non-collection use cases. That does not make sense to me personally.
while there many punny cases where nil is handy, it is not clear to me that this is one of them :)
FWIW, my intent with the above was to simply make ClojureScript match Clojure's semantics. (While also only guessing at what those semantics truly are, and cheating by looking at the implementation.)
I hear ya. I don’t think it would be a bad thing if cljs deviated in disallowing
empty on things that are not collections or nil
And, I failed in my analysis, missing the behavior for records :slightly_smiling_face:
so records are tricky in that they are collections and will probably pass any type check but throw in the impl
(Part of me feels like simply waiting on these kinds of things where there is a bit of uncertainty for the point when specs are written, which nails things down, in a sense.)
the problem is that there are 100s of methods that require this kind of interpretation :)
Clojure actually has a test-empty test that checks things like
(and (= (empty "abc") nil))
but I think that’s more tests written from looking at the impl, than tests that should predict the behavior
I think I would spec it as
(s/fdef clojure.core/empty :args (s/cat :c (s/nilable coll?)) :ret (s/nilable coll?))
I forget, is there a desire / goal to ultimately spec the core functions, where feasible?
loading 100s of specs on startup is unlikely to make anyone happy wrt startup time
so I think you would want them in a separate namespace (from the existing macro specs) so you can choose whether and when to load them