Fork me on GitHub
#cljs-dev
<
2018-11-05
>
dnolen15:11:51

@mfikes I'm thinking we should apply 2596 before releasing - I also want to take a look at 2957

mfikes16:11:16

Ahh, right, has to be. 🙂

mfikes16:11:36

Yeah, that is a low-risk one to apply.

borkdude16:11:01

I wonder how @dnolen views core changes that come out of the attempt of spec’ing cljs itself. I’m sure there’s more that can be optimized 🙂

dnolen16:11:05

@borkdude do you mean if specs find bugs?

borkdude16:11:13

@dnolen well, 2956 is only relevant if you want to instrument cljs.core/=. my question is how far would cljs go to support that use case

borkdude16:11:43

if the changes are minor, I guess it can’t hurt

dnolen16:11:49

to me 2956 is just a bug

dnolen16:11:10

there's no reason instrumenting core should not work

👍 4
borkdude16:11:40

ok. a fundamental problem we ran into was instrumenting cljs.core/apply. that one seems very tricky

dnolen16:11:05

right, less sure about that one

borkdude16:11:16

the reason is that spec-checking-fn uses apply on the instrumented function, so you get a loop

dnolen16:11:38

probably have to live with that

👍 4
borkdude16:11:39

I guess it’s ok to have that as the exception

dnolen16:11:03

you could probably make apply work as a special case - but I'll leave that as an exercise for someone else 🙂

dnolen16:11:47

@mfikes I'm thinking this two issues are pretty minor - we should probably just go

dnolen16:11:21

we can patch them up in a follow up release - I'm sure other things are going to crop up anyway

dnolen16:11:04

feel free to merge in the announce post, I'll ping the mailing lists and the channels during lunch

mfikes16:11:59

Ok, yeah—no matter what we do, we won’t find bugs until people start using 1.10.439

mfikes16:11:49

I’m AFK for lunch, but will merge the announcement post when back

mfikes16:11:31

@dnolen announcement post merged I

mfikes16:11:35

We can find all the ancillary merges (compiler option doc updates, etc) since they are tagged—I can take care of those when back

mfikes17:11:59

Looks like the date of the post needs a tweak; will fix and merge when back

mfikes18:11:54

Fixed the date and merged in all the ancillary site updates for this release https://github.com/clojure/clojurescript-site/commits/master

dnolen18:11:59

👍:skin-tone-4:

mfikes21:11:28

The Graal.JS support in 1.10.439 is still compatible with the GraalVM RC9 that came out today. Hopefully we are home-free at this point.

didibus22:11:58

I was wondering about the new type inference. Is it able to warn on:

(defn add [a b]
  (+ a b))

(add "2" 2)
?

mfikes22:11:04

@didibus That's still an open area of research. With an experimental compiler change, we can infer function parameter types, and your example results in

cljs.user=> (add "2" 2)
WARNING: Type mismatch calling add: expected [number number], got [string number] instead at line 1 <cljs repl>
Read more about it and try it yourself here https://gist.github.com/mfikes/1e2341b48b882587500547f6ba19279d

didibus22:11:08

I'm all in on this proposal. I don't really feel this conflicts with Spec at all. Even Clojure could benefit having this. Simple type checking goes a long way to improve usability. Better error messages, quicker. In ClojureScript, it also protect the user against its weaker runtime type checking, basically the automatic coercion around arithmetic.

mfikes22:11:46

TBH, my opinion has evolved to: We should leverage statically derivable type info to generate optimal code whenever possible. I think we can have a dynamic lispy language and eat our cake too.

didibus22:11:45

Inference is even better for sure. But I feel there's a case to be made for static analysis of type hints. I mean doesn't CL support this fully, and no one complains that its made it less dynamic. Most people actually complain Clojure is less dynamic then CL because not everything can be reified due to the underlying JVM.

didibus22:11:53

It's like a very dynamic, very loose version of gradual typing, but I feel it gives you like 80% of the potential bug reports that a much more complicated static type system would.

didibus22:11:57

I don't expect to be type hinting everything because of this. I'd sprinkle it here and there, maybe I won't ever, but at least having core with them and inference would improve error messages. Also, the whole thing just generates warnings so

didibus22:11:23

Also, might be able to derive type hints from specs in certain cases.

didibus23:11:24

And we're not really introducing type semantics. Like you can define your own types. I think this is the big difference. You can say this takes a string, list, map. But it doesn't speak of the structure of the list or the map, mandatory keys, and the type of their values etc. This is still all left dynamic and for Spec to cover.

dnolen23:11:05

type-hinting is probably unlikely to ever be used for checking outside of numerics, specs are just better suited for this

dnolen23:11:39

definitely no future plans for type-hints that aren't mostly perf oriented