This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-22
Channels
- # 100-days-of-code (1)
- # adventofcode (21)
- # announcements (2)
- # beginners (44)
- # calva (1)
- # cider (2)
- # cljdoc (16)
- # cljs-dev (70)
- # cljsrn (29)
- # clojure (66)
- # clojure-austria (1)
- # clojure-europe (4)
- # clojure-finland (1)
- # clojure-hamburg (1)
- # clojure-italy (24)
- # clojure-nl (3)
- # clojure-uk (127)
- # clojurescript (30)
- # core-typed (3)
- # cursive (34)
- # data-science (2)
- # datomic (16)
- # duct (17)
- # editors (1)
- # emacs (4)
- # figwheel-main (4)
- # fulcro (40)
- # hoplon (2)
- # instaparse (5)
- # kaocha (4)
- # leiningen (1)
- # luminus (4)
- # nrepl (46)
- # off-topic (5)
- # onyx (2)
- # other-languages (55)
- # parinfer (3)
- # protorepl (4)
- # re-frame (33)
- # reagent (6)
- # reitit (13)
- # ring-swagger (5)
- # shadow-cljs (26)
- # spacemacs (4)
- # sql (8)
- # testing (27)
- # tools-deps (21)
- # yada (1)
I think this plus the predicate stuff is probably enough information for helpful nullability checking if you spec an fn
I looked at letting Closure do this and it would be really ugly - but now that we have so much type info flowing through - might as well use spec to (optionally) tell you when things don't look quite right
The and
/ or
(and if
) inference patch similarly narrows the inferred type of many forms: Instead of a union, you oftentimes get a single type instead of a set. (https://dev.clojure.org/jira/browse/CLJS-2869)
> helpful nullability checking if you spec an fn I was wondering if this has anything to do with clojure.spec 🙂
are these macro or really fn specs that are used for this? the more specs you add for core fns, the better the inference?
originally way back when I wanted return type inference so that user fns could get type inference w/o the ugly explicit annotations
the idea being that we hint the core protocols and fns, and then everybody else gets hinted
and return type inference will always give us something meaningful for standard library usage
this means we can trivially compare what you say the fn spec is with what type inference tells us
even in the ClojureScript case you probably want to do this when running the whole build, could get fiddly at the REPL
It seems that type inference alone can sometimes give you info about nullability: If a fn returns string
vs. #{string clj-nil}
, for example. But yeah, if you see nilable
on the spec that's another direct way of deducing that.
but the moment a user writes a spec - then they've already taken that step and probably would be happy to be told something is wrong at compile time
Oh, by "nullability checking", do you mean a subset of type checking, constrained to nullness?
There is that other stuff I was doing (not a patch yet, but in a branch), that infers parameter types. From that you can see general type mismatches. But, it is much more aggressive (and difficult) than nullability checking.
yeah I think inferring parameter types is probably too much - I was thinking about that
and what if the users loads specs to core functions, will this somehow improve things automagically?
The unsolved problem with parameter type inference (in the branch I was messing around in) is that it gets into situations where you need multiple passes, and you start to feel like you are informally building things that Hindly-Milner solves. If a parameter type can easily be derived from a spec, you more rapidly get to the same place.
Yeah, I’m still worried we may compile code based on inferred types that becomes invalid as types change (REPL case)
I think we definitely want to put aggressive type driven optimization behind a flag to avoid that
Exactly - :static-fns
is about perf related to arity info that can go stale, we may need something for types. (The type info can still exist and be useful for type checks, warnings, etc, but if that new flag were enabled, compiled code would be disallowed from leveraging and statically depending on types for perf reasons)
Hrm—maybe the meaning of :static-fns
could grow to cover this aspect. (Or that might be confusing.)
Nah, maybe :static-fns
should remain about dispatch, like its more aggressive cousin :fn-invoke-direct
Hi!
def
'ing a var in another namespace "works" in 1.10.339, setting the var when the namespace exists or outputting an error when it doesn't.
1.10.439 fails during compilation with an NPE.
This is definitely in undefined-behavior land - used as a dev-time-only hack - but I suppose sharing it wouldn't hurt. Here's a minimal repro gist:
https://gist.github.com/aisamu/3d860dd329436361113d144a4a162832
(And thank you for the superb work on CLJS! 🙂)
I suspect its related to https://dev.clojure.org/jira/browse/CLJS-712 as well but definitely not intended to work at all
@aisamu probably not going to spend any time on that one - you can accomplish that with set!
Yup, that was the workaround! The main issue was finding that as the culprit, since the thrown NPE only points to the file path, with no further cause/location
def’ing a var in another namespace is not supported in JVM Clojure as far as I know, hence it should probably not be supported in CLJS either
@dnolen any thoughts on the dotted-symbol issue in general? should they even be checked at all or is the unchecked behavior intentional?
the hacky patch I did for shadow-cljs keeps finding small issues like this https://github.com/juxt/bidi/issues/189
Yup, that was the workaround! The main issue was finding that as the culprit, since the thrown NPE only points to the file path, with no further cause/location
I've pondered but never really bothered as there's too much code out there that uses that pattern due to it being it included since day 1