Fork me on GitHub

The CLJS compiler emits arity warnings at compile time. Any chance Clojure JVM could get this one day?


I’ve found it ironic before that CLJS does the arity warning - with an underlying platform (JS) that doesn’t care about arity really; while CLJ doesn’t - with and underlying platform (JVM) that does definitely care


of course, it’s really probably just a result of the compiler impl though


The difference is that if you've run your clojurescript code, it may not work as you expect. The clojure code won't run at all though. It's really an attempt to make clojurescript more like clojure.


Who has a community-accepted reaction gif for "premature solution space conversation"?

😂 4

yeah that works


You'll gain a reputation if you repeat that enough

Alex Miller (Clojure team)17:03:17

you hear something every morning for several years and it starts to sink in :)


Does Rich beat you guys with this stick a lot? :) (in a good way of course)


No no, all in good jest. Maybe British sarcasm not coming across :)


seriously, arity checking is overrated


i get the appeal, but the economics don't make sense to me


something like spec/instrument could give you nested arity checking on every input argument


(nested meaning you pass in some larger shape, and the whole thing is checked)


arity is but one dimension


premature? this feature should have landed 10 years ago 😉


I mean, hotfixing in the REPL is cool ( but this problem wouldn't have happened if I had ran my own linter or if Clojure emitted some basic warnings 😉


I'd rather have one basic piece of feedback than pages full of spec output in many situations

Alex Miller (Clojure team)17:03:15

spec does not produce pages of output so that's a strawman


it depends. I had spec produce pages of output earlier today.


also spec is optional. many functions will be unspec'ed. the compiler can already infer something is not going to work. emitting a warning seems the sane thing to do.

👍 4

the pages full happend with a spec that we have on our component system


unrelated to the arity error btw


this is a really unfocused complaint. I'm lost between arity checking and what this stuff is about spec output


well, you brought up spec as an alternative, that is why.


seems like the arity argument was made quite clear


I get that clj compiler isn’t likely going to rapidly change this


but think the conversation seems really dismissive here

Alex Miller (Clojure team)17:03:39

I'm not being dismissive


I'm just saying there are degrees of what gets checked, different choices about when things get checked, and there need to be serious evaluations of things


not leading with solutions


cost/benefit analyses

Alex Miller (Clojure team)17:03:32

I think it's a reasonable thing to want, I just don't know the complexity of effort/feasibility vs the gain vs the priority of everything else we have in the queue

👍 4

I understand that too.

Alex Miller (Clojure team)17:03:33

clojurescript is doing whole program analysis, doesn't that make it more feasible to know if the arity is "right" vs clojure where functions can be rebound to have different arities?

Alex Miller (Clojure team)17:03:30

I've never talked about this with Rich


it's not very common to rebind functions to different arities maybe?


yeah, perhaps that clears up the “irony” comment I made before, among other things


I'll argue against a compiler error for that since it would mean you couldn't eval code when you had arity errors in a path that you are not trying to invoke -- it would potentially make RDD harder because work-in-progress code might become uncompilable.


I was surprised to see arity warnings in CLJS really (coming from doing CLJ only for a long while)


I think tools like clj-kondo, eastwood, fill a real gap. If I were to present Alex with a proposal to "add arity checking to the compiler", he would tell me to go back to the drawing board and get a problem statement

👍 4

@seancorfield in CLJS this isn't an error, it's just a warning message from the compiler. Compare to e.g. warn on reflection.

Alex Miller (Clojure team)17:03:32

well that seems reasonable


also, in CLJS isn’t it the case that it doesn’t check anonymous fn’s?


Ah, sorry, I thought you were arguing for a compiler error. Yeah, a warning wouldn't really bother me too much.

Alex Miller (Clojure team)17:03:21

this is not really on my radar - I do not see a high quantity of complaints specifically about this, but maybe they are just a subset of "errors are bad" that has not been well analyzed


btw I'm not really complaining, I just find it a useful thing from CLJS, but you could be right in that CLJS has more information at compile time

Alex Miller (Clojure team)17:03:49

I'm not saying I'm right necessarily, maybe I'm just missing that


clj-kondo should just check this for us - the answer is now clear

Alex Miller (Clojure team)17:03:46

I appreciate having clj-kondo to help with stuff like this during dev :)


@borkdude @mikerod I hope I didn't seem dismissive

Alex Miller (Clojure team)17:03:47

just in general, clj function objects are intentionally (to my eye) absent of signature information


ok, I'll run clj-kondo next time before I push to production 😛


I’ve hooked kondo to our CI - errors break the build :)


Wait, you weren't? 🙂


With emphasis on the "you" 🙂


we have a pretty big codebase and I didn't want to force it on my colleagues


I do use it in my editor


but now that some of my colleagues are using it, and one has suggested doing using it in CI, may be a good idea to do it soon

borkdude18:03:27 cloc output:

Clojure                         383           7862           2764          56302
ClojureScript                   261           9247           2296          51294
ClojureC                         56           1559            705          11184
Still about a 1000 linting errors + warnings. Getting rid of them slowly but surely as I'm working on the code.


We run Eastwood in our CD pipeline. Lost count of how many times it has saved me.


I always get in trouble for leading with a solution rather than a problem, and when I approach something from the problem side, way better/more comprehensive/satisfying solutions emerge

hammock 4
Alex Miller (Clojure team)17:03:51

IFn doesn't tell you anything about arities


@ghadi (on my end) I think you clarified it all and I appreciated your explanation. I probably just misread the tone originally.


Arities end up seeming more complicated than I originally even considered too.

Alex Miller (Clojure team)17:03:01

I have not ever talked about this specifically with Rich, but in general he favors things that leave options open

Alex Miller (Clojure team)17:03:34

by requiring less here, you allow your code to work as things expand in the future

Alex Miller (Clojure team)17:03:05

that's a very Rich way to think about things

🙌 4

what does an arity warning have to do with requiring less?

Alex Miller (Clojure team)17:03:36

sorry, I'm probably not being clear


do you mean metadata on IFn about arities?

Alex Miller (Clojure team)17:03:11

yeah, functions don't require anything saying what's allowed

Alex Miller (Clojure team)17:03:26

so that widens the possibility of things that can be invokable


giving information is something distinct from saying/checking what is allowed imo

Alex Miller (Clojure team)17:03:13

well how do you check without the info?

Alex Miller (Clojure team)17:03:50

you're trying to do a check from the call side

Alex Miller (Clojure team)17:03:19

you could check when invoking a var what the current known arities are and emit a warning. there's a cost to that check of course, but you'd probably happily pay that at the REPL for the warnings (or at "build" time)


yeah, I mean, providing information on IFn is something else than IFn saying: you're not allowed to call me, I will throw.


the compiler information processing is something that doesn't have to interfere with the execution


a bit like the check you made in core.async: it's not going to alter existing programs, it just emits a bit of feedback

Alex Miller (Clojure team)17:03:55

the majority of the time I spent working on that was trying not to affect the performance for programs not doing the check


And arity mismatch is only one dimension of "called it wrong"


highly likely to catch an arity mismatch before it leaves your laptop


I guess CLJS works differently enough that it makes sense there, since you typically only compile prior to deployment


I mean, on the JVM you take the compiler with you into production

Alex Miller (Clojure team)17:03:13

to really bake your noodle, Rich has played with some things to make all calls named parameter based so there is no fixed arity

👍 4

I’ve dreamed about this - a language without positional arguments, only named slots


where maps – not lists – get applied to fns


thanks for the conversation - gotta run now


lul, I’m so used to cursive highlighting arity errors that I’d totally forgotten they’re not compiler-checked


I say that because it does add some amount of credence to the idea that tooling goes a long way here


Likewise for Joker which is hooked up to an auto-linter in Atom for me.


joker doesn't lint cross namespace arities btw, that was one of the first things I wanted to have in clj-kondo


I hadn't actually noticed that until you just mentioned it. Which I guess shows how rarely I have arity errors in my code? 🙂


Is clj-kondo compatible with the Atom linter stuff?


well, they aren't too frequent here either, but you know, there's always that one function in a code-path you don't hit during development, and heck, not even in the tests


to get cross namespace linting in your editor, you'll have to make a $PROJECT_ROOT/.clj-kondo directory, then clj-kondo will save analysis information there as you visit your files.


I'll take further questions to #clj-kondo


btw, sorry if I came across a bit unfriendly, didn't mean to. feeling a bit cranky this week.

Alex Miller (Clojure team)19:03:44

I think we can all relate

💯 12