This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-02
Channels
- # announcements (14)
- # beginners (133)
- # cider (27)
- # cljs-dev (7)
- # cljsjs (13)
- # clojure (105)
- # clojure-dev (58)
- # clojure-italy (1)
- # clojure-nl (17)
- # clojure-russia (33)
- # clojure-spec (5)
- # clojure-uk (154)
- # clojured (1)
- # clojurescript (35)
- # cloverage (4)
- # cursive (35)
- # datomic (58)
- # duct (8)
- # editors (9)
- # emacs (15)
- # events (1)
- # figwheel (47)
- # figwheel-main (132)
- # hyperfiddle (5)
- # immutant (29)
- # instaparse (21)
- # luminus (3)
- # off-topic (5)
- # onyx (5)
- # overtone (5)
- # pedestal (8)
- # re-frame (7)
- # reagent (6)
- # reitit (3)
- # schema (2)
- # shadow-cljs (178)
- # spacemacs (49)
- # specter (2)
- # sql (1)
- # tools-deps (110)
Wow, this is interesting! Also, it could mean it's easier to port clojure to other VMs (less Java code).
I recently created a library for personal use that takes the spec/instrumentation approach to checking the args of clojure.set functions (https://github.com/eerohele/flowthing.set.specs.alpha). I was curious about your views on whether the set functions should allow nil args. I see your library disallows them, which makes sense, but I was just curious whether you considered allowing them…?
I had not considered the question of allowing nil arguments, taking the straightforward "sets only" approach. Have you tried out their implementations with nil arguments to see if they all handle them cleanly?
Well, depends on what you consider clean... they won't throw any errors if you pass in nil, as expected, but they might return nil instead of a set. set/index
and set/map-invert
are exceptions: if given a nil arg, they return an empty map instead of a nil. There are some test cases here that illustrate how they behave with nil args: https://github.com/eerohele/flowthing.set.specs.alpha/blob/master/test/flowthing/set/specs/alpha_test.clj
Now that you have led me to consider the question of whether nil args should be allowed for functions in clojure.set, or not, I can definitely say I have a preference for the stricter "no nil, only sets" version. However, I don't have any well-thought out explanation for why. 🙂
Heh, I hear ya, I've been struggling with it for a while now. I'm inclined to agree with your sets-only approach, though. I allowed nils in my library pretty much only because instrumentation checks all the code currently in play (including dependencies) and I figured the chance that someone somewhere down the dependency chain passes a nil arg to a set function is pretty high.
I haven't yet made the final decision on which way to go, though... I think that one thing that speaks for a sets-only approach is that allowing only set args makes things more predictable. If you pass in a set, you'll always get back a set.
Then again, I don't know whether any core function specifically disallows nil args…
I gave it a quick try and discovered that clojure.tools.nrepl, for example, has code can call set functions with nil args. I didn't track down what going on exactly, but it appears to occur somewhere in here: https://github.com/clojure/tools.nrepl/blob/d5e29f4473f4444d56858d67d123b9c5375d6353/src/main/clojure/clojure/tools/nrepl/middleware.clj#L92
So I think with instrumentation, at least, disallowing nil args might not be feasible. If you could only enable instrumentation for my-namespace.* or something, then maybe.
Promenade https://github.com/kumarshantanu/promenade 0.6.0
is released to Clojars, adding support for (1) wrapping functions that throw exceptions, and (2) early termination in reducing functions
Further discussion in #promenade
Clojurists Together is funding cljdoc and Shadow CLJS for the next three months: https://www.clojuriststogether.org/news/q3-2018-funding-announcement/