Clojurians Log v2

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

:rich:

yeah that works

You'll gain a reputation if you repeat that enough

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)

you make it sound bad

heh

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 (https://twitter.com/borkdude/status/1243211177703997441) 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

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

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

in what context?

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.

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

https://clojurians.slack.com/archives/C06E3HYPR/p1585243456043500

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

but think the conversation seems really dismissive here

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

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

I understand that too.

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?

good point

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

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

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.

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

ok

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

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

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

me too

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

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

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.

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

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

that's a very Rich way to think about things

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

sorry, I'm probably not being clear

do you mean metadata on IFn about arities?

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

so that widens the possibility of things that can be invokable

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

well how do you check without the info?

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

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

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

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

thanks for the conversation - gotta run now

later

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.

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

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

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

http://covid19.doctorevidence.com/ cloc output:

Clojure                         383           7862           2764          56302
ClojureScript                   261           9247           2296          51294
ClojureC                         56           1559            705          11184

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

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

@seancorfield https://github.com/borkdude/clj-kondo/blob/master/doc/editor-integration.md#atom

Thank you!

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.

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

I think we can all relate

:)

I'll take further questions to #clj-kondo

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

where maps – not lists – get applied to fns

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