cljs-dev

ClojureScript compiler & std lib dev, https://clojurescript.org/community/dev
lilactown 2019-11-21T07:10:00.384600Z

I need a way of notating the return type of a macro for inference purposes

lilactown 2019-11-21T07:10:02.384800Z

possible?

thheller 2019-11-21T11:00:12.386Z

@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

2019-11-21T12:03:35.388200Z

(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

dnolen 2019-11-21T14:56:44.388600Z

@mhuebert I'm pretty sure there's still a round of issues around warn on infer and deftype/record

dnolen 2019-11-21T14:57:11.389200Z

there's a bunch of other things that came up via @roman01la and the plan is to address these in the next release

dnolen 2019-11-21T14:58:01.390100Z

@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 2019-11-21T14:59:05.390500Z

@mhuebert feel free to file that specific bug

1
thheller 2019-11-21T15:04:18.392200Z

@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

thheller 2019-11-21T15:08:05.392700Z

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");

thheller 2019-11-21T15:08:18.393Z

basically just wraps it in a function

lilactown 2019-11-21T16:07:36.395Z

one 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 work

2019-11-22T20:06:18.402100Z

Are you sure it’s not an issue with ilk ? I can’t repro this using analyzer directly

lilactown 2019-11-22T20:06:59.402300Z

I am not using ilk for my actual code

lilactown 2019-11-22T20:07:27.402500Z

I'll see if I can create a minimal repro and put it on GitHub

lilactown 2019-11-21T16:08:12.395600Z

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...

dnolen 2019-11-21T18:44:18.396700Z

for the above - yeah make a ticket

dnolen 2019-11-21T18:44:37.397100Z

re the macro problem - I don't know what you can about that - you have to expand

lilactown 2019-11-21T20:05:00.397300Z

ok, thanks!

borkdude 2019-11-21T22:30:55.397600Z

@lilactown what about a return type tag on bar?

lilactown 2019-11-21T22:32:40.398300Z

haven’t tried it. these are macros that are emitting calls to external JS so it’s a little harder to annotate return types

lilactown 2019-11-21T22:34:48.400400Z

specifically, I’m trying to emit something like this:

(useMemo #(str "a" "b"))
and in my macro, annotate the expression with the same type as the function passed into it

lilactown 2019-11-21T22:36:07.401500Z

(`useMemo` does some stuff under the hood but essentially will always return the same type as the function passed into it)