🚀 go-pugleaf

>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 to automagically remove parts of MCL that are
>   not used by your application.
 
A tree shaker would be nice, if one could conveniently declare a list of 
functions etc. which might be used and therefore should not be removed.

>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.

The issue of alternative distribution forms is important. It involves not only 
the size of what may be redistributed to end users of apps created in MCL, but 
also the functionality of those apps. Obviously, Apple needs to prevent people 
from "reselling" MCL, and that is the reason why the compiler must be excised 
before redistribution. I believe other ways of reducing the value of what may 
be redistributed should be considered. Removal of the development environment 
is an obvious choice. 

This would make MCL extremely attractive for writing compilers of special 
purpose languages, and for writing systems which contain such special purpose 
languages. If necessary, a small fee (<<$500) could be charged for 
redistribution with compiler but without development environment.

I believe that AppleScript will make programming languages a much more 
important part of the Macintosh user interface. This will make it attractive to 
provide many applications with end user programming languages (usually quite 
similar to/extensions of AppleScript). Additionally, increased depth and 
complexity of graphical user interfaces will make it more attractive to compile 
plans created at runtime by user manipulation (as for example in ThingLab). 
With a way to redistribute the compiler, MCL would be great for writing all 
those future applications.

>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.

This would be nice for developers with lots of homemade MCL applications on 
their hard disk(s) (I'm working on becoming one of "them".). How about making 
the development environment a big init? That might make tree shaking the rest 
of each application easier as well. In such a scenario, developers could keep 
exact end-user versions of apps on their hard disk. All end-user versions could 
have the property that they call the development environment IF-AND-ONLY-IF(an 
error occurs AND the development environment init is present). This would allow 
convenient debugging without version confusion 


Oddmund Mogedal
Norwegian Institute of Technology
oddmund@idt.unit.no