Fork me on GitHub

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

👍 3

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

👍 3

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