I started looking the and/or macro problem and I think it's going to have to wait - I think the ClojureScript analyzer needs to broken up first - while I think this can be done mostly w/o breaking compatibility there's a couple of cases around dynamic vars that seems difficult to surmount
so would rather hold off until the ns enhancement (property based requires, global libs) stuff lands
if your tooling is accessing cljs.analyzer
directly now would be a good time to stop doing that and start using cljs.analyzer.api
if something is missing make it known
the goal here is just make the analyzer less monolithic and more modular
i.e. move the inference stuff into it's own ns
have an ns for different compiler passes
after the refactor then we can look at and/or
and remove other related macro level perf hacks
I have never looked at cljs.analyzer.api
but I'll try to take a look what shadow-cljs
uses from cljs.analyzer
and whats missing
it is fairly deeply integrated though so I don't have high hopes for this being possible but I can easily adjust so do whatever you want to do
@thheller the plan would be to only move dynamic vars - all defs would be aliased - getting a sense of how much you depends on dynamic vars would be helpful. it's also probably possible to support the old dynamic vars even though internally we use different ones
I'm not against the refactor servicing both internal cleanup and outward compatibility