SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.

Except without a better way to package a binary it will be compared as one.

That distinction isn't important here, though. It is the reason the resulting file is so big, but for all practical purposes it's a binary that statically links the full CL runtime.

I wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?

SBCL does treeshaking? I thought it just dumps the image.

Well that would explain it. Any idea why they don't tree shake?

Because no one wrote one. There were some attempts but nothing which would work now. Delivering small applications does not seem to be a focus of SBCL users.

https://www.snellman.net/blog/archive/2005-07-06.html

There is also the possibility to compress the image. See :compression option when saving an image:

http://www.sbcl.org/manual/#index-g_t_0040sbext_007bsave_002...

Commercial Lisp implementations like LispWorks and Allegro CL have a treeshaker for delivery, but that's not too surprising, since these products are for developers of applications and the users pay for such features.

eval is the root of all evil. String to symbol lets you introduce anything.

In lisp eval does not take a string as its input, but a form, i.e. a linked list, containing the program to execute. Maybe you confuse it with JavaScript or Python eval (or the like) where the function both reads in a string and runs the program it parsed from that string. There are diverse functions to convert a string to a symbol in different lisps.

Perhaps i'm rusty.

in this case

    (funcall #'+ 1 2 3)

or the more scheme-ish

    (apply '+ '(1 2 3))

i think the symbol plus gets evaluated to #<function+> and then is called with 1 2 3 - CL will do apply, of course, not sure about scheme and funcall. I'm totally willing to accept my mental model is wrong, i don't have an interpreter handy.

So if that's true, you run into this problem:

    (funcall (string->symbol "+") 1 2 3)
    (apply (string->symbol "+") '(1 2 3))

maybe string->symbol does not introduce in to the function namespace, but i bet there's a way or a flag to do it.

so anyway, at the end, you run into this problem:

    (funcall (string->symbol "any-random-function") 1 2 3)
    (apply (string->symbol "any-random-function") '(1 2 3))

this makes tree shaking hard.

you could, of course, look for the handful of ways to bind symbols to functions, maybe do constant folding and include a minimal set if the compiler can prove what's actually needed.

but in general i think tree shaking is hard when you can load things like that dynamically.

(funcall #'+ ...) does not do a symbol lookup and does not need to retrieve the function from a symbol in Common Lisp. (funcall '+ ...) would retrieve the function from the symbol.

Treeshakers are generally used for application delivery in Lisp. When you do that, then one usually limits the amount of use of runtime dynamics. Typically you can tell the treeshaker what to remove or what to keep: the compiler, the symbol table, debugging info, etc etc.

Allegro CL and LispWorks have extensive facilities for this.

http://franz.com/support/documentation/10.0/doc/delivery.htm

http://www.lispworks.com/documentation/lw70/DV/html/delivery...

More briefly, in a half decent implementation, the + symbol is involved in the processing of (funcall #'+ ...) in the same ways and at the same times as it is involved in the plain call (+ ...).

Some CL compilers even don't save an image. An extreme example is mocl. mocl applications for a 64bit iPad start at 1 MB size.

Other examples of CL compilers not saving an image are ECL and WCL.

The ECL manual had the terminology a bit wrong, but it actually does not dump an image.

https://common-lisp.net/project/ecl/static/manual/ch34.html#...

WCL:

https://github.com/wadehennessey/wcl

> For example, the executable for a Lisp version of the canonical ``Hello World!'' program requires only 20k bytes on 32 bit x86 Linux.