cljs-dev 2025-06-05

been poking around at tree shaking issue w/ the cljs.core - I don't think the problem really has anything to do w/ printing anymore - I think the issue is actually protocols - and I think it can be fixed

❤️ 4

which tree shaking issue?

the fact that just using a few functions in cljs.core doesn't lead to a fairly small artifact

this would also mean that protocols are a problems when used in libraries

anyways, I used to think that printing was problem but it's really not

(-lookup ...) has the same effect all by itself

last time I checked using any of the collections causes a lot of things to stay alive

I'm sure there might be a couple of other problems

and a fairly large chunk having to do with Ifn invoke stuff

but the protocol one should be fixable

IFn is a protocol so it suffers for sure

it is not only a protocol given that it affects where/how the thing is called

setting the other problems aside

(-lookup ...) is one of the easiest issues to understand

it involves no other cljs.core lib calls

it's a fn prototype and some fns

like the foo.cljs$ifn$x ? foo.cljs$ifn$x(...) : foo.call(...)

yet it drags in cljs.core

I noticed that protocols don't declare the actual interface they are expecting

so maybe this interacts badly w/ the types that declare implementing it

so the protocol site is purely duck typed

and finally after the assertion that we have the thing we want, we might need a cast

basically (-lookup ...) is exactly the kind of case I think that Closure should understand, but it's not working

one interesting thought is that if the cljs.core tree shaking issue can be sorted out a "light weight" mode would be interesting

i.e. a flag to emit copy-on-write data structures instead of the persistent ones

👍 3