> But I should be able to know, through class inspection, whether my > 'main' program depends on a class which uses, say, the clojure.zip > namespace, and decide whether or not to include it. Or so I am > wondering.
There are impediments to that, too -- your namespace might require another, and so on, and your namespace can refer to symbols further down the chain without itself including the necessary `require` form. If you had the entire classpath available, and were willing to transitively examine the entire tree (probably including code-walking) then you might be able to solve this problem... but as soon as you hit a call to `read` where *read-eval* is not known to be false, or a call to `eval`, or maybe even some uses of reflection, you have to give up. Furthermore, some code adjusts itself at compile-time according to its environment (e.g., clojure.contrib.logging, which generates different functions depending on which logging libraries are available). That's not very amenable to static analysis. > I suppose a better question might be: would a tree-shaker have a > reasonable chance of shaking a typical Clojure jar, or are there too > many dynamic obstacles to a good analysis. I'm not sure it's worth solving this through low-level analysis. Far better, IMO, is to rely on correct descriptors and namespace definitions -- convention and configuration can save the day. If you can sweep the hard parts under the proverbial rug, the rest can be solved in a handful of lines of code! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
