cljs-dev

ClojureScript compiler & std lib dev, https://clojurescript.org/community/dev
dnolen 2020-08-23T18:19:39.002400Z

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

👍 1
dnolen 2020-08-23T18:19:51.002800Z

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

dnolen 2020-08-23T18:20:36.003700Z

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

dnolen 2020-08-23T18:20:47.004Z

if something is missing make it known

dnolen 2020-08-23T18:22:20.005100Z

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

dnolen 2020-08-23T18:22:27.005300Z

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

dnolen 2020-08-23T18:22:44.005700Z

have an ns for different compiler passes

dnolen 2020-08-23T18:24:10.006500Z

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

👍 1
thheller 2020-08-23T19:08:34.007200Z

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

thheller 2020-08-23T19:09:39.008Z

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

dnolen 2020-08-23T23:08:44.010200Z

@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

dnolen 2020-08-23T23:09:17.010800Z

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