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
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