Re: MCL Size (was: MCL support for MOP)

[dblamkins@aol.com]

> We'll probably be
> looking into a few ways to reduce the size of MCL (though probably
> not for 2.1). Some ideas are:
> 
> 1) A tree shaker to automagically remove parts of MCL that are
>    not used by your application.
> 
> 2) Make the development environment be optional, or distribute 2
>    MCL applications: with & without development environment. Maybe
>    even a third application that has just Common Lisp with no
>    application framework.
> 
> 3) One or more shared libraries for the different pieces of MCL.
>    This will allow small MCL applications at the expense of some
>    large inits.
> 
> Feedbac
k please. Do you need these facilities? Other ideas?x

On the surface, #3 seems most attractive when it comes to being able to have
lots of small MCL apps on my hard disk. For distributing apps to others using
this scheme, I'd have several concerns: (a) that there were never any
backward compatibility issues - i.e. my users should never have to worry
about replacing their shared library with an earlier version, (b) that you
provide appropriate Installer scripts, and tools for customization, so that
end-users don't have to worry about which files they should copy into their
system folder, and (c) that there is no permanent overhead associated with
the shared libraries - i.e. any shared code should be purged once there are
no applications using it.

I have no idea what benefits tree-shaking could provide, in terms of size
reduction. Could you give us some examples?

Dave