This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-28
Channels
- # aleph (48)
- # announcements (3)
- # bangalore-clj (1)
- # beginners (131)
- # cider (30)
- # cljdoc (6)
- # cljs-dev (53)
- # cljsrn (24)
- # clojure (312)
- # clojure-austin (2)
- # clojure-europe (4)
- # clojure-finland (6)
- # clojure-nl (24)
- # clojure-spec (24)
- # clojure-uk (66)
- # clojurescript (185)
- # core-async (46)
- # cursive (10)
- # data-science (9)
- # datomic (15)
- # devcards (2)
- # emacs (50)
- # fulcro (28)
- # jobs (1)
- # jobs-discuss (2)
- # kaocha (11)
- # lein-figwheel (12)
- # nyc (1)
- # off-topic (105)
- # other-languages (80)
- # pedestal (6)
- # re-frame (50)
- # reagent (5)
- # reitit (1)
- # remote-jobs (2)
- # ring (10)
- # rum (1)
- # shadow-cljs (10)
- # spacemacs (19)
Guy who wrote Clojure book in 2012 and wrote many Clojure OSS libs: https://twitter.com/cemerick/status/1111110485510942720
cemerick is a notable troll on twitter (I still like him). OCaml's super cool tho and I do miss the typechecker at times
I wrote some small applications with it a little over a year ago. I participated a lot in the ReasonML community early on
I had a similar amount of experience with Clojure at the time, and our team was trying to decide what to build our new system on top of. I debated between Clojure and OCaml and landed on Clojure š
I certainly would like some hand-holding by the compiler, esp. when dealing with code (not data) ā arity exceptions or unresolved symbols are examples of this, perhaps though we could have more of those?
The CLJS compiler already warns about this when you compile the code. It would be nice if CLJ did the same
Turns out that while people could write extremely indirect and dynamic code, most of the time they donāt ā so covering for the usual use cases with static analysis can be a real time-saver, if you get feedback in your editor.
right, thatās what Iām trying. it wonāt be perfect, but covers 90% of the cases
@borkdude are you going to eventually cover the joker use cases too? or always complement them?
Iāll prioritize things that it doesnāt do yet, but they may overlap. E.g. the wrong arity only worked in joker for calls within the same namespace, but for clj-kondo they also work across namespaces
Maybe thatās what joker does, kind of, Iām not sure. Since itās a light weight interpreter
Iām mainly focussing on a lightweight tool that I can use to get āstupidā errors really fast. E.g. arity checking while editing CLJS files without a backing REPL
I guess you'd need some fixture data for a kind of static analyzer that could exercise runtime scenarios
I already have that. We have a 30kloc app with tons of deps. I just have to analyze the classpath to get a ton of warnings and errors š
30kloc CLJ and 18kloc CLJS actually. And this is only the main app, we have other components too š
I mean, almost like for generative tests, so that a static type system can do some run-time-ish things
I do expand certain macros already, so you can see that (-> 1 (inc 1))
is an arity error.
Just wondering how you could maybe capture some dynamicity of the repl for static analysis at compile time
I plan to scan fdef
s to offer a very limited/basic form of type checking on literals
Yeah, but joker recreates the interpreter in go... why not just use a full clojure interpreter?
then youāre basically implementing core.typed and Iām not planning to do that š
that would be like implementing āevalā which is currently not supported with GraalVM š
Iām not sure which problems the joker currently detects that cannot be done with static analysis
BTW, Cursive also uses static analysis, might also be a source of inspiration. Iām not using it ATM
could your re-find utility be used to potentially provide a predictive-next-token thing for an ide?
I was thinking of a feature like:
(s/fdef foo :args (s/cat :i int?))
(foo "foo") ;;=> invalid argument
(foo _) ;;=> type int expected in hole
Yeah, like, if the the thing that follows a thing is expected to be a literal string, maybe the IDE can start the string form for you, with the cursor between the quotations
... I don't know... just wondering if re-find's inference system can be used to infer code templates or whatnot for certain code contexts in an ide
I made a toy little utility https://github.com/johnmn3/coal-mine2vec that can find analogies between relations between functions. I've been wondering how I could combine it with your re-find tool to do some interesting kinds of inference.
I guess your tool can be used to give suggestions: āalso see ā¦ā on clojuredocs for example
Or re-find could also use it. It would have to run in JavaScript though. Maybe the result of the analysis could be emitted to some static EDN graph structure
Re-find is pretty simple. It just tries to find functions whose specs match the given in/output. Thereās not really anything āinferencyā to it, or maybe Iām misunderstanding what you mean with inference.
Well, the word2vec thing is just looking over swaths of text and if it sees things in similar proximity to one another, but in different contexts, it'll fill in the blank for you... which seems similar to your re-find... Not sure how they could be combined yet though...
you can create an automatic network of related functions this way right? and this could be useful in suggesting things
But in conjunction with your re-find thing, you could eliminate fns that don't work from a type perspective
and if you're talking about pure functions, you could interpret some candidate options a priori and see if they're invalid suggestions