This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (4)
- # beginners (47)
- # boot (22)
- # cider (7)
- # clara (1)
- # cljs-dev (8)
- # cljsrn (21)
- # clojure (180)
- # clojure-argentina (13)
- # clojure-gamedev (1)
- # clojure-italy (5)
- # clojure-poland (4)
- # clojure-russia (17)
- # clojure-spec (19)
- # clojure-uk (33)
- # clojurescript (107)
- # cursive (61)
- # data-science (1)
- # datomic (7)
- # emacs (69)
- # euroclojure (1)
- # graphql (1)
- # hoplon (11)
- # immutant (43)
- # jobs (1)
- # leiningen (3)
- # off-topic (5)
- # om (10)
- # onyx (2)
- # parinfer (52)
- # pedestal (11)
- # re-frame (31)
- # reagent (23)
- # ring-swagger (3)
- # schema (2)
- # specter (7)
- # unrepl (9)
@mfikes Thanks, I’m interested to know if it’s any better, or at least not worse, and if the completion etc is noticeably worse.
I’m running your beta version. Will let you know. Hah, I actually realized I needed to upgrade my Cursive license. I actually had license number 6. 😀
FWIW, I’ve started using “hippie” completion in IntelliJ, where it simply cycles through directly-entered textual completions, rather than popping up the little completion GUI. It seems to give slightly different results, but I like it.
It’s probably useful for CLJS I guess, where the interop completion is still not so useful.
I’m going to add type inference soon, so hopefully that will make it much more useful in the presence of mild annotation (like the new auto externs stuff)
Cool! It will be interesting to see how Cursive type inference compares to what exists internally in the ClojureScript compiler.
Right, with all the new Node stuff I should be able to take advantage of the DefinitelyTyped stuff that Typescript uses too.
If Cursive starts with simple things like marking the string in
(+ 2 "a") that will be amazing 🙂
I think those were suggested a few years ago, perhaps related to some stuff that Closure could help with
Right, the wiki page makes it sound like it’s a thing, but I couldn’t find any examples in the CLJS project itself (which is where I would have expected them).
Even if Cursive had a roughly equivalent type inference engine matching what ClojureScript has, it would be nice to see it statically doing it in the UI.
Yes, that works well for Clojure, although there’s a lot more I could do with it. It’s mostly used for completion right now, not for inspections.
But it’s possible to catch things like
(instance? x String) now, which would help me a lot - I always get that wrong.
Here is the bit that essentially means “this operation works on numbers” so that that ClojureScript compiler can detect type mismatches: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/core.cljc#L1021
(It is not a normal type hint, but a mechanism the analyzer uses to emit
The recent addition on master to check types passed to
aset is essentially custom code inside the analyzer that has been hard-coded to know what those core functions accept.
Right. dnolen was actually talking about using spec for the CLJS project, but I suspect that’s a long-term goal.
So the arithmetic warnings are actually produced by the CLJS compiler? Or does it create hints which allow Closure to catch them?
s/fdef was being used, the analyzer could probably detect a lot of stuff statically 🙂
Here is the point where the analyzer is looking at the
js* special form that
+ expands to, and doing arithmetic type checks: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3026
That essentially results in type checks for macros, and recently this was added that allows a similar thing to be done for functions: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L3467-L3479
The salient aspect is that it is all being done by looking at the inferred types in the AST and checking to see if function invokes are valid given things that mark what those functions require.
The cool thing is the type inference is in there (it knows what the types are, if it can infer them). The uncool thing is it doesn’t know what parameters need to be. That will take spec, I guess.
Yes, it is done during the analysis phase of compilation. It has to be conservative and not emit diagnostics if there is not enough informatino.
The tricky part about type inference is that it’s much more powerful if you infer function param types from call sites, but it’s difficult to do that in a performant way.
Right, in that example,
elem are of type
'any and will be assumed to be valid arrays, via this bit here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/analyzer.cljc#L2998
Yeah, so it only catches gross type mismatches. It is very easy to have code where you can say nothing about its correctness.
Actually, I saw the other day that it looks like there are some
clj-* type tags too, but I couldn’t find any examples of them. Do you know what they’re about?
Hah, even some rudimentary checks would be nice. It is surprising how often code is committed that has calls with incorrect arity. A common example is
(ex-info "hello"), which no Cursive user would commit. 🙂
For those of you using parinfer, there’s a new demo up of a new Smart Mode, which will hopefully replace the Indent/Paren mode distinction. Please try it out and let us know what you think: https://shaunlebron.github.io/parinfer/demo