2 ms·

And? When I last checked sbcl didn't support it. Are you implying that has changed? Neither did sbcl support cross compiling. To the best of my knowledge all y

And? When I last checked sbcl didn't support it. Are you implying that has changed? Neither did sbcl support cross compiling. To the best of my knowledge all you can do with sbcl is save an image. When I was looking in to this I read through many discussions where the developers appeared hostile to the idea of implementing these features. A common refrain I encountered was that tree shaking is unnecessary because the core images are compressed.

reikonomusha 4y ago
You can delete data from the image if you want. We used to do it: scrub all doc strings, inlining data, etc. It's trivial. In 2022, removing a few megabytes of data doesn't seem worth the maintenance cost of the feature. In other words, for most users, it's a non-problem.
- oblio 4y ago
  Tree shaking isn't data removal, it's dead code removal. And assuming he doesn't want what he wants is kind of in bad taste. You don't know his requirements.
  - reikonomusha 4y ago
    As far as I'm concerned, as a Lisp programmer, code is data. :) Yes, and what exactly constitutes "dead code"? Tree shakers rely on heuristics that can fail in practice. There is provably no way to remove functions from a Lisp image and guarantee your application to work. LispWorks has a "tree shaker", but has umpteen options to tame it so your application doesn't inadvertently break. Fortunately, it is possible to remove these functions if you, an application developer, so please. Nothing stops you. It's not even difficult. But SBCL has not implemented these (potentially fallible) heuristics for you, because (and only because) an insignificant number of users would find shaving a little binary size off to be valuable at the expense of program correctness.
- kazinator 4y ago
  In 2022, if you're linked to libc.so, it's probably substantially bigger than your Lisp image, and so that's where you'd want the tree shaking. Good luck! The kernel supports manual tree shaking: "make menuconfig" and prune away.

reikonomusha 4y ago

You can delete data from the image if you want. We used to do it: scrub all doc strings, inlining data, etc. It's trivial. In 2022, removing a few megabytes of data doesn't seem worth the maintenance cost of the feature. In other words, for most users, it's a non-problem.

oblio 4y ago
Tree shaking isn't data removal, it's dead code removal. And assuming he doesn't want what he wants is kind of in bad taste. You don't know his requirements.
- reikonomusha 4y ago
  As far as I'm concerned, as a Lisp programmer, code is data. :) Yes, and what exactly constitutes "dead code"? Tree shakers rely on heuristics that can fail in practice. There is provably no way to remove functions from a Lisp image and guarantee your application to work. LispWorks has a "tree shaker", but has umpteen options to tame it so your application doesn't inadvertently break. Fortunately, it is possible to remove these functions if you, an application developer, so please. Nothing stops you. It's not even difficult. But SBCL has not implemented these (potentially fallible) heuristics for you, because (and only because) an insignificant number of users would find shaving a little binary size off to be valuable at the expense of program correctness.
kazinator 4y ago
In 2022, if you're linked to libc.so, it's probably substantially bigger than your Lisp image, and so that's where you'd want the tree shaking. Good luck! The kernel supports manual tree shaking: "make menuconfig" and prune away.