🚀 go-pugleaf

Bill & friends,
 
>We'll probably be looking into a few ways to reduce the size of MCL (though
>probably not for 2.1).
 
1) A tree shaker - could be neat, but sounds like a lot of effort given the
sneaky ways that fruit can be accessed.
 
2) Make the development environment be optional - I have used languages like
ProIcon which come with a 'runtime' version for distribution, and must admit
that I rather like them.  It also gives the development team scope for
additional optimisations within the runtime.  It gets my vote.
 
3) One or more shared libraries - technologically attractive, but probably the
clumsiest when it comes to distributing apps to ordinary users.  We have enough
trouble with the INIT required for the dongles that we have to use!
 
Overriding these, to me at least, is the eventual availability of Dylan.  If
the policy stated in the book is set - that MCL will remain a full CL
implementation - and a lean, mean commercially-viable Dylan is released for the
Mac, then I for one would be very happy to use MCL for its strengths, and Dylan
for commercial work (sometimes exploring and doing initial development in MCL,
and finishing off in Dylan).  I think that could take a lot of emphasis off
MCL's size and memory requirements, which would fit with
>though probably not for 2.1
too?
 
Howard.