Fork me on GitHub
#announcements
<
2018-08-02
>
mauricio.szabo14:08:58

Wow, this is interesting! Also, it could mean it's easier to port clojure to other VMs (less Java code).

flowthing11:08:10

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…?

andy.fingerhut16:08:43

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?

flowthing06:08:58

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

andy.fingerhut15:08:17

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. 🙂

flowthing05:08:52

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.

flowthing05:08:29

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.

flowthing06:08:38

Then again, I don't know whether any core function specifically disallows nil args…

flowthing10:08:03

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

flowthing10:08:23

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.

Shantanu Kumar12:08:26

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

👍 5
Shantanu Kumar14:08:33

Further discussion in #promenade

danielcompton23:08:28

Clojurists Together is funding cljdoc and Shadow CLJS for the next three months: https://www.clojuriststogether.org/news/q3-2018-funding-announcement/

41
❤️ 18
clj 7
💯 6