Printing from functions called by tagged literals is dumping the output in my main.js. I guess that stage is so early in compilation that any printlns end up in the output. Is that too esoteric of a use case to jira?

@john you can print to *err*. *out* is reserved for code generation

ah k

So I got this tagged literal hack working, in order to do conditional requires, depending on if some thing exists in the analyzer's constant-table:

(defn exists? [[extant then? else?]]
  (if (-> env/*compiler* deref :cljs.analyzer/constant-table
        keys str (clojure.string/split #" ") (->> (some #{(str extant)})))
    then?
    else?))

Then you can do like:

(ns my.core
  #my/exists?
   [clojure.core.protocols/datafy
    (:require [clojure.datafy :as d]
              [cljs.pprint :as pp])
    (:require [cljs.pprint :as pp])])

Is anything in this hack likely to be unsupported at some future point?

hrm I wonder if the latest inference stuff handles cases like this https://groups.google.com/d/msg/clojurescript/s7dg_4m3RyI/qDUN7dGfEAAJ

Hrm. My take is that #{nil clj-nil} is not definitely known to be a non-number, but we probably don't handle that case correctly and trigger a warning when we shouldn't.

Easy to repro. I'll file a JIRA.

Or, hold on, is this because the typecheck knows it might be nil? Hrm.

We seem to let this by OK: (fn [^{:tag #{clj-nil number}} x] (dec x)) But if you replace number with nil then a warning is emitted.

@mfikes if you look at the above though shouldn't the and reject clj-nil as a possibilty

(and ssv-next ...)

@dnolen Ahh, right, I see what you are saying. We currently have extremely simple predicate-induced inference, that isn't sophisticated enough to "see" that.

Even a simple extension to what we have: (when (some? x) (dec x), we don't really have a tag to indicate that "this is any value but nil`

Digging into that email to see if I can at least figure out what changed... 🙂

@mfikes sure but it does seem like a simple win to know that (if x ...), x must be truthy thus you can at least reject clj-nil from what is inferred

this is actually a multi-year complaint about the arithmetic inference stuff

but now with the predicate bits it seems relatively straightforward

Yeah, more and more is coming into reach 🙂

For this particular one, it doesn't seem to be the clj-nil that is tripping the typecheck but the nil

This doesn't trigger a typecheck warning: (fn [^{:tag #{clj-nil number}} x] (dec x)) This does: (fn [^{:tag #{clj-nil nil}} x] (dec x))

right but again I think both of those should get rejected in a simple true branch

I agree

FWIW, the zprint warning goes away with ClojureScript master. This is because, while 1.10.443 infers the type to be #{clj-nil nil}, master infers it as #{clj-nil any}, which doesn't trigger the warn. This is neither here nor there, with respect to improvements, but alas, it is a fact that the warning goes away for this particular body of code.

huh ok

In the spirit of forward progress: https://dev.clojure.org/jira/browse/CLJS-3034

I'm interested in this one; it almost seems trivial given our current setup for predicate-induced inference.

Example of the improved behavior: https://gist.github.com/mfikes/9e9521b932b5376442b4fe31a25b8969