is there a generic tree-shaker out there? I'm thinking of doing one. it
can't be that difficult.
in particular, I'd like to be able to limit its search to specific
packages, so that it only operates on my modules.
primarily I want to do this in order to be sure that certain "3rd party"
included modules are just included because I need one function...
I delivered to my customer last week, and our standalone executable was
20 megabytes. (yes, that's 20MB) that includes lisp, compiler, clim2,
and our stuff. our stuff is 12 of the 20.
-- clint
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>is there a generic tree-shaker out there? I'm thinking of doing one. it
>can't be that difficult.
There's no portable way to find out what functions or global variables are
referenced by compiled functions. How can you write a portable tree-shaker
without this? You could operate on source code, but then you'ld only be
able to look at your own code.
>in particular, I'd like to be able to limit its search to specific
>packages, so that it only operates on my modules.
Do you mean that it should only shake out the parts of your modules that
aren't used?
>I delivered to my customer last week, and our standalone executable was
>20 megabytes. (yes, that's 20MB) that includes lisp, compiler, clim2,
>and our stuff. our stuff is 12 of the 20.
If you only limit the tree-shaking to your modules, you'll have to leave in
the compiler, clim2, the interpreter, etc. These are usually the things
one tries to get rid of with a tree-shaker.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
>In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>>is there a generic tree-shaker out there? I'm thinking of doing one. it
>>can't be that difficult.
>
>There's no portable way to find out what functions or global variables are
>referenced by compiled functions. How can you write a portable tree-shaker
>without this? You could operate on source code, but then you'ld only be
>able to look at your own code.
I have previously suggested that the Lisp language standard functions
include 'alpha' and 'beta' reduction functions, a la the lambda calculus.
Before I get deluged with complaints about making Common Lisp even
larger, hear me out.
It should be possible to take a Lisp S-expression that is in the
correct 'syntax' to be a lambda expression, and so long as the bound
variable is a lexically scoped variable, the name of the variable
should not matter, so a symbol substitution operation is well-defined,
and should be a standard function. The inclusion of such a function
as a standard function would precisely pin down those symbol instances
that were bound, and which were not, and eliminate some of the hand
waving in the current language standard. In addition to making the
standard clearer, such a function would be useful in macro-expansions,
and in the 'beta reducer', below.
Similarly, it should be possible to take a Lisp S-expression that is
in the correct 'syntax' to be a lambda expression, together with the
arguments to which the lambda expression will be applied, and perform
a careful substitution of the arguments into the S-expression, in such
a way that no additional name collisions will be produced. Such a
substitution will in general require alpha renaming of some existing
statically scoped variables through the use of the alpha renamer,
above. (This function would presumably do lazy evaluation w/o
caching.)
Both of these capabilities are already found in every Lisp compiler
capable of performing function 'inlining', so it makes sense to offer
these capabilities portably for the use of sophisticated macros.
Once these capabilities for _variable names_ are in hand, one can
contemplate the same kinds of capabilities for function names and
global (special) variables. Of course, these are more difficult,
since they run into the 'eval' problem which is not encountered with
lexically (statically) scoped variables.
Nevertheless, one can come up with relatively straight-forward
approximations which would be useful for solving tree-shaking sorts of
problems.
I would also recommend a portable way to inquire of compiled functions
and closures what global symbols they reference, and the ability to
perform a 'substitution' which goes into the closure/compiled function
static reference table. In this way, one could handle name collisions
which occur even in compiled code.
(I have also suggested these 'alpha-renaming' capabilities for the
cretinous linking loaders which C uses to link its global variables
and function names. This would enable the ability to portable handle
C-level name clashes without having to recompile.)