This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # autochrome-github (1)
- # babashka (9)
- # beginners (112)
- # bristol-clojurians (2)
- # calva (26)
- # cider (10)
- # clj-kondo (31)
- # cljs-dev (40)
- # clojure (114)
- # clojure-austin (1)
- # clojure-dev (112)
- # clojure-europe (22)
- # clojure-germany (5)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-norway (1)
- # clojure-spec (10)
- # clojure-uk (96)
- # clojurescript (39)
- # core-logic (5)
- # crux (15)
- # datomic (40)
- # fulcro (34)
- # graphql (17)
- # jobs (3)
- # kaocha (4)
- # leiningen (10)
- # luminus (1)
- # malli (3)
- # meander (44)
- # midje (2)
- # off-topic (40)
- # pathom (5)
- # re-frame (8)
- # reitit (8)
- # ring (3)
- # ring-swagger (4)
- # shadow-cljs (83)
- # spacemacs (96)
- # tools-deps (16)
- # vim (4)
- # yada (20)
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
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.
something like spec/instrument could give you nested arity checking on every input argument
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
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.
this is a really unfocused complaint. I'm lost between arity checking and what this stuff is about spec output
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
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
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?
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.
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
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
just in general, clj function objects are intentionally (to my eye) absent of signature information
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:
Still about a 1000 linting errors + warnings. Getting rid of them slowly but surely as I'm working on the code.
Clojure 383 7862 2764 56302 ClojureScript 261 9247 2296 51294 ClojureC 56 1559 705 11184
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
@ghadi (on my end) I think you clarified it all and I appreciated your explanation. I probably just misread the tone originally.
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
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
I guess CLJS works differently enough that it makes sense there, since you typically only compile prior to deployment
to really bake your noodle, Rich has played with some things to make all calls named parameter based so there is no fixed arity
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
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? 🙂
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.
btw, sorry if I came across a bit unfriendly, didn't mean to. feeling a bit cranky this week.