Fork me on GitHub
#cljs-dev
<
2020-08-23
>
dnolen18:08:39

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
dnolen18:08:51

so would rather hold off until the ns enhancement (property based requires, global libs) stuff lands

dnolen18:08:36

if your tooling is accessing cljs.analyzer directly now would be a good time to stop doing that and start using cljs.analyzer.api

dnolen18:08:47

if something is missing make it known

dnolen18:08:20

the goal here is just make the analyzer less monolithic and more modular

dnolen18:08:27

i.e. move the inference stuff into it's own ns

dnolen18:08:44

have an ns for different compiler passes

dnolen18:08:10

after the refactor then we can look at and/or and remove other related macro level perf hacks

👍 3
thheller19:08:34

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

thheller19:08:39

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

dnolen23:08:44

@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

dnolen23:08:17

I'm not against the refactor servicing both internal cleanup and outward compatibility