Welcome! Please see the About page for a little more info on how this works.

0 votes
in Compiler by


I noticed the following:

user> (-> '(some-> 1 inc) clojure.walk/macroexpand-all (clojure.pprint/pprint ))
 [G__427566 1]
 (if (clojure.core/nil? G__427566) nil (inc G__427566)))

Namely, values which are known at compile-time such as scalars ideally wouldn't be tested for nilness at runtime.

A more realistic use case can be found here: https://github.com/clojure-emacs/refactor-nrepl/blob/cb939222d45bc20926202868922bd3e457d59b8f/src/refactor_nrepl/ns/tracker.clj#L33-L35

Fixing this would improve performance and additionally make linters like Eastwood happier (I'm tweaking it to omit this fault in the meantime)

1 Answer

+1 vote
selected by
Best answer

Checking for "values known at runtime" is a non-trivial operation to implement and this pattern has a trivial workaround (and probably minor improvement in perf in most cases thanks to the jit). So, I'm not convinced this makes sense to do.

Also, the realistic use caes you point is actually not a runtime constant but an expression that must be evaluated so is not an example.
Thanks, sounds fair enough. It's possible to observe that `clojure.core/symbol` never returns nil, and that accordingly the `some->` macroexpansion has some redundance. However it's hard to automate that without a type system, or something like static analysis backed by clojure.spec annotations. Neither is a 'thing' these days.