Re: why is tree-shaking hard?

[yost@Yost.com (Dave Yost)]

In article <CONVERSE.95Mar2141828@orca.uchicago.edu> timoshenko,
converse@cs.uchicago.edu writes:
>I understand that allowing EVAL would make tree-shaking impossible,
>(or at least "fruitless" :-) since you would not be able to predict in
>advance which portions of the language would be needed at run time.
>I'm curious what complexities have to be addressed even if you
>rule out EVAL.

I say why worry about eval, funcall, apply, and
whatever.  If you're doing a tree shake, it's because
you want to let go of a lot of stuff, and you are
claiming that anything you really want to be there at
runtime is referenced somewhere, say by keeping a
global list of the things you want available at runtime
whether they're clearly referenced in your code or not.

I could imagine someone programming a spreadsheet which
would translate user formulas and/or macros to lisp for
eval-uation into machine code.  The functions and
objects which must be available at runtime to serve the
user could simply be held in a list so they don't get
shaken off.

Thus, a tree shaker could be free to be very aggressive and
even a little dumb, with some burden on the programmer.

Do any tree shakers work this way?

 Dave Yost
     @    .com