Tree shakers are not written because they 'are cool', but because one wants to deliver small applications with it. But that's not the focus of SBCL development and never was. People can't tell you much about it, because there were only few attempts made in that direction for SBCL. Some Common Lisp implementations have tree shakers - especially the commercial ones. But it's a rarely used tool.
#sbcl is not THE Common Lisp community. Best not to generalize from an IRC channel to a very diverse group of people using a dozen different implementations.
> Tree shakers are not written because they ‘are cool’
Yeah this is all very serious business. Also, one of the most curmudgeonly responses you could have given.
> #sbcl is not THE Common Lisp community
This is not my sample size of one opinion. I’m just throwing one in the pot for the very widely held opinion of the Common Lisp community being curmudgeonly.
It's work and SBCL is maintained mostly by volunteers, who may have their own agenda. Sometimes there is funding from commercial projects. So far maintaining a treeshaker wasn't high on the agenda, even though the project runs for some years now.
If you shell out serious money for your 'very serious business' the commercial implementations Allegro CL and LispWorks provide maintained tree shakers and all kinds of fancy application delivery features.
> throwing one in the pot
not very motivating...
You might check out the link I've gave you above, instead.
I may not have made myself clear. I don’t want someone else to write a tree shaker for me, I want an intro project to understanding the internals of a performant Common Lisp compiler, and I want to do the work to write a tree shaker myself. I’ve seen a few implementations, but they all come with notes explaining that they’re sketchy and experimental. I mostly wanted to know how to push them past that point into being robust.
Tree shakers require that you look at every function-bound symbol and determine if that symbol appears in the call graph of the main function(s) or in an isolated call graph. The functions that follow the call graph exist in most Common Lisps but they are not standardized; they're implementation-dependent. That's part of the reason tree shakers aren't widespread. Another reason is that if you're using the compiler in your runtime, even isolated parts of the call graph can still be useful, so tree shaking becomes something of a policy decision rather than a pure algorithm.
...and just as a follow-up, once you've dug into the problem enough to discover it's surprisingly difficult to define what is "the right thing" for a tree-shaker in Lisp to do, you realize that even if you build it, it doesn't buy you much. That's why we tend to sound curmudgeonly about the issue. It's a valuable learning exercise, so feel free to dig in. You'll gain some valuable insights into what makes Lisp special.
Hmm, the usual treeshaker might not tell you much about the internals of the compiler itself (a compiler is just one part of a Lisp system based on runtime, interpreter, various libraries, etc.), since the ones I've seen work over already compiled code. It's an interesting project, but not that easy for a complex piece of software like SBCL - depending on what the goals are.
See for example:
https://github.com/roswell/roswell/blob/master/lisp/dump-sbc...
> Common Lisp community
#sbcl is not THE Common Lisp community. Best not to generalize from an IRC channel to a very diverse group of people using a dozen different implementations.