This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-01-31
Channels
- # aleph (9)
- # bangalore-clj (1)
- # beginners (115)
- # cider (16)
- # clara (20)
- # cljs-dev (47)
- # cljsrn (50)
- # clojure (70)
- # clojure-dusseldorf (2)
- # clojure-italy (16)
- # clojure-sanfrancisco (1)
- # clojure-spec (9)
- # clojure-uk (37)
- # clojurescript (132)
- # cursive (21)
- # datomic (36)
- # dirac (53)
- # fulcro (34)
- # graphql (6)
- # hoplon (96)
- # jobs (2)
- # juxt (2)
- # keechma (2)
- # leiningen (5)
- # off-topic (3)
- # om (2)
- # om-next (3)
- # parinfer (3)
- # re-frame (17)
- # remote-jobs (1)
- # shadow-cljs (57)
- # specter (12)
- # sql (43)
- # unrepl (11)
- # 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 ☔ org 😄
Sorry for the ping 😅
@richiardiandrea Here is the discussion that led to the creation of that organization: https://clojurians-log.clojureverse.org/cljs-dev/2017-07-05.html
Ok cool so my small adopted lib would not be a good fit there 😸
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
@anmonteiro That was it. Thanks.
If empty
were defined as
(defn empty [coll]
(when (implements? IEmptyableCollection coll)
(-empty coll)))
it would seem to more closely match the semantics of Clojure's 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.
regarding empty and things that don’t work with it ….
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
semantics that align with that idea are good ones
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)
while having 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?
probably one for @alexmiller
as always, I would suggest reading the docstring
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 :)
(empty nil) ;; => nil
is probably useful
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
so records are tricky in that they are collections and will probably pass any type check but throw in the impl
in Clojure at least
(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
(ignore the and there, that’s some test detritus)
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?
yes, and I’ve worked on it at times
one of the issues is whether you proactively load them
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
For now, I've "self-declined" https://dev.clojure.org/jira/browse/CLJS-2489 as being premature, especially if the spec for empty
ends up invalidating the questionable reversed engineered semantics in that ticket.