I wonder if at some point, it makes sense for ClojureScript releases to coincide with Clojure’s. Roughly think that if you want to use new stuff in Clojure 1.11.0, there would be a similar ClojureScript release with the same features and version number released around the same time.

The "main" version 1.9.X, 1.10.X already mostly align but beyond that I don't think that it makes sense to "match". CLJS has a lot more moving parts and could probably use more frequent releases.

Perhaps achieving this, while still having more frequent releases could simply involve delaying things that are 1.11.0-specific

whats the point of delaying things though? what do we gain by sticking to the CLJ release schedule?

It might make things simpler for end users, or people writing portable libraries that require something in 1.11.0

anything in mind that would have been better in the past when doing that?

dunno I think the version system we have now is fine. "patch" number increases don't matter much whether we go from 339 -> 439 or 1 -> 2

its always gonna be different than CLJ

A concrete example might be something like swap-vals!, which has :added meta. Perhaps things like that could be delayed and added in a ”matching” release.

(Not saying that patch appeared in an odd release—I haven’t looked up its history. But it serves as an example.)

don't we already sort of do this? CLJS 1.10 has features from CLJ 1.10. CLJ is just taking longer to release.

You can also coincide with GCC releases 🙂

Hi @mfikes Just wanted to say I came across your work on cljs expression type inference (https://gist.github.com/mfikes/3837f510aad3e8ff766eb9071ef66b2b) recently and it's pretty awesome. What needs to happen for it to make it into master?

I'd like to leverage it as part of a zero-runtime-cost cljs hiccup compiler, since inference would make the user experience much nicer (i.e., it'd reduce the places where one would need to manually annotate forms with metadata about whether they can be handled by React)

The cljs compiler branch from your gist demo has some issues: It fails to compile some of my project dependencies. Not sure if that's related to the type inference changes or just because it's based on an older version of the compiler.

I'd love to understand the status of the inference stuff, and in particular if there's anything I can do to help it land in master.

Would be happy to jump on a call/skype if you'd prefer to chat instead of Slack.

@kevin.lynagh Inference is one of the themes David is interested in https://clojurians-log.clojureverse.org/cljs-dev/2018-10-27/1540683337.008300 The primary challenge, as I see it, for these inference patches is 1) Ensuring correctness 2) Ensuring no perf regressions (compilation perf) For correctness, I think the best way to proceed is to have people simply use patches and comment on them (indicating that they work or not). That lets us know whether they are OK to apply. What I tend to do is use builds from https://github.com/mfikes/patch-tender as much as I can in order to soak things and ferret out any regressions. If there is a particular patch that is causing grief, I'd be happy to dig deeper. I suppose the challenge for you currently is isolating which patch might be causing the issue. In that branch it looks like there are 4 tickets applied: CLJS-2873, CLJS-2869, CLJS-2866, CLJS-2865. It is interesting that you have a use cases that would actually rely on type inference. (Generally it is done behind the scenes and just speeds things up.) The concept that the compiler absolutely needs to know the type of an expression in order to produce correct output would be odd, but perhaps that's not what you are really saying.

If it is easier for you to chat via Skype—that's cool with me as well.

Thanks for this info @mfikes! I'll look into patch-tender and see if I can isolate the patch that was causing an issue.

For my use case, incomplete information would be fine, since that reduces to the base case of throwing a warning at the user and making them annotate themselves.

I'll writeup on my website a bit more details about my planned use case and these notes about using patched versions. May take you up on a Skype later once I have some more specific questions. For now, this overview is exactly what I needed. Thanks!

Cool!

Is it possible to get the env necessary for type inference within a function called by a macro? I'm wondering if I can patch some existing code (which doesn't pass along &env to the function I'm overriding).

Hmm, so you have a function called at macroexpansion time, but the macro isn’t passing &env. My guess would be no.

Yeah, that's what I thought, but wasn't sure if there's some accessible global state within cljs compiler I could access = )