This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-21
Channels
- # aleph (2)
- # announcements (2)
- # babashka (10)
- # beginners (117)
- # calva (11)
- # cider (19)
- # clj-kondo (27)
- # cljs-dev (24)
- # cljsjs (1)
- # clojure (73)
- # clojure-europe (3)
- # clojure-italy (2)
- # clojure-nl (47)
- # clojure-spec (23)
- # clojure-uk (28)
- # clojurescript (71)
- # cursive (7)
- # data-science (17)
- # datascript (1)
- # datomic (7)
- # duct (23)
- # emacs (23)
- # fulcro (6)
- # graalvm (41)
- # jobs (2)
- # luminus (1)
- # malli (1)
- # off-topic (151)
- # pathom (1)
- # portkey (10)
- # re-frame (12)
- # reitit (17)
- # shadow-cljs (158)
- # spacemacs (14)
- # sql (8)
- # tools-deps (17)
- # xtdb (9)
@lilactown macros don't have a return type (usable for inference). the code they generate may have but how you annotate that depends on the code it generates
the problem I have at the moment is that I’m using type inference within a macro, but the body obviously hasn’t fully expanded yet. so I can’t infer in the case when it’s nested:
(d/div (d/div "foo"))
the first d/div
macro will expand, and try and infer the type (d/div "foo")
which will come back as any
Once it expands, the code it generates is annotated with the correct type(extend-type com.cognitect.transit.types/UUID cljs.core/IUUID)
with *warn-on-infer*
, that code results in
Cannot infer target type in expression (. com.cognitect.transit.types/UUID -prototype)
is this a bug? I see a related issue but it is specific to extending Object
- https://clojure.atlassian.net/projects/CLJS/issues/CLJS-2862?filter=allopenissues&orderby=priority%20DESC&keyword=extend-type%20infer@mhuebert I'm pretty sure there's still a round of issues around warn on infer and deftype/record
there's a bunch of other things that came up via @roman01la and the plan is to address these in the next release
@thheller re: goog.module - the docs suggest bundling now instead of individual loads? or does that still work anyway regardless of the recommendation (this would be a serious drawback IMO if not)
@dnolen the goog.module stuff just needs pre-processing so that it actually becomes loadable. it can still be loaded using the goog debug loader though. they even have a "transpile" mode that does this on the fly in JS but I haven't used that. in shadow-cljs I just run all the goog code through :whitespace once so it rewrite goog.module to the loadable code
FWIW the rewrites it does fore goog.modules are pretty minimal
goog.loadModule(function(exports) {
"use strict";
goog.module("goog.math.Long");
goog.module.declareLegacyNamespace();
const asserts = goog.require("goog.asserts");
const reflect = goog.require("goog.reflect");
the problem I have at the moment is that I’m using type inference within a macro, but the body obviously hasn’t fully expanded yet. so I can’t infer in the case when it’s nested:
(d/div (d/div "foo"))
the first d/div
macro will expand, and try and infer the type (d/div "foo")
which will come back as any
Once it expands, the code it generates is annotated with the correct typeone more question re: type inference. is there a correct way to notate the RHS in a let-binding? what I'm finding right now is:
(let [foo ^string (bar)]
(ilk.core/inferred-type foo))
the ^string
notation is effectively ignored. however, notating the name foo
does seem to workAre you sure it’s not an issue with ilk
? I can’t repro this using analyzer directly
I can turn all of these into JIRA tickets and poke at them in the cljs compiler, if there's not already a solution for them...
@lilactown what about a return type tag on bar?
haven’t tried it. these are macros that are emitting calls to external JS so it’s a little harder to annotate return types