Fork me on GitHub

@dnolen Does that exclude @mfikes prototype then? I guess I'm not sure what numerics cover. I'm talking about warning on primitive type mismatch only. Once you implement it for arithmetic functions like +, -, etc. I don't see why you'd go out of the way to prevent using it for other functions?


@didibus FWIW, the bottom half of that gist explains my motivation for that exploration: It is not to infer parameter types for the purpose of type checking, but instead for optimal code generation. In short,

(defn xyzzy [x] 
 (subs x (dec (count x))))
can be compiled down to
function cljs$user$xyzzy(x){
return x.substring(x.length - 1);


Yes, I know. And that's awesome. But type checking is a spectrum. For example, ClojureScript performs less of it than Clojure. Such as (+ 1 "1") not being checked at runtime. Now, ClojureScript has some type checking done at compile time, where it will warn on possible type mismatch. Your branch takes it even further. So, I'm very much on the pro dynamic side of the spectrum. I don't want to be limited by my type system, or have to switch to a type based paradigm. I'm onboard with using datastructures for data modeling, and not being forced to declare anything extra about my code just so it lets me run it. But, if I'm already forced to define type hints for performance, and the machinery is there to also warn me of potential bugs in my code, then why not? Similarly for inference, why not warn me of strange things that are most likely bugs? I understand the: because it would take a lot of work and it's not the priority argument. What I'm unsure I understand is if there are other reasons and what those would be?


Yeah, even though the changes in that branch were not motivated by a desire to warn on the kind of type mismatch your example illustrates, it does indeed do that type check. Why? My only rationale is: Once you’ve inferred parameter types and also inferred argument types, why not type check? 😀


To be honest though, the fact that the compiler today doesn’t generate optimal code for xyzzy is really what is driving me.


(The optimized variant runs about 4 times faster in :none mode.)


> Once you’ve inferred parameter types and also inferred argument types, why not type check? Yes, sorry, erm, what I meant was: Why not, not type check? If the machinery is there. I felt like @dnolen was aluring to some other reasons why it would be restricted to numerics and maybe even simply performance without even type mismatch warnings.


@didibus ClojureScript already has type checking (thanks to GCC), if you want less bugs, you can use it


Wow that looks pretty dated. Is it still working as advertised?


sure, GCC uses doc comments for type declarations


@rarous Hum, that's good to know. That said, I'm not really looking for static type checking. I'm looking for something that can warn me of potential bugs, without me being required to change anything in my source code. So, something that can infer types, or leverage my existing type hints, which I have to include currently because of performance reasons. @mfikes’s branch is really promising in that regard. That's also why I don't buy the argument that Spec is better suited to this. Spec is additional work on my part. Though I wouldn't mind automatic inference from my existing Specs which could also warn of potential inferred Spec mismatches 😛


@didibus Clojure doesn't really do that much out of numerics - it falls out of JVM stuff


anyways, while appreciate the enthusiasm in this area - I've already stated what we're interested in for the time being


type hints are not for type checking - no amount of discussion is going to change this - this is exactly Clojure's own stance


fwiw our tests pass with cljs 1.10.439

👍 4

our build got 8 seconds faster 🙂


@borkdude what were they before?



339: Elapsed time: 77.649 sec
439: Elapsed time: 71.927 sec


@borkdude for the advanced build?


not going to be a huge change there


oh ok - interesting


we use boot, not cljs.main, does that matter?


I don't think it should, but unsure


parallel, I’ll try


I have a project, where switching from 1.10.339 to 1.10.439 and also enabling :parallel-build dropped it from 21.5 s to 9.1 s.


I had parallel-build enabled a while back, but I disabled it when I was looking for a weird error


(To measure this stuff, be sure to blow away ~/.cljs and also do a clean build in your project, and use :compiler-stats true.)


with boot there’s nothing to clean afaik


right to ignore other aspects of tooling time


it seems pretty common for some tooling setups to take more than 10 seconds


ok, turning that on


Output with 439:

Compile sources, elapsed time: 21441.956571 msecs
Compile sources, elapsed time: 1103.507717 msecs
Elapsed time: 60.640 sec


now with 339:


Compile sources, elapsed time: 25784.826339 msecs
Compile sources, elapsed time: 1536.513698 msecs
Elapsed time: 66.553 sec


@borkdude thanks, yeah some projects will definitely have more modest gains


I’m ok with every release that’s not slower 🙂