[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MCL size/distribution (was: MCL support for MOP)
- To: email@example.com
- Subject: RE: MCL size/distribution (was: MCL support for MOP)
- From: firstname.lastname@example.org
- Date: Sun, 10 Jan 1993 17:18:38 +0100
- Cc: .@idt.unit.no
>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
Norwegian Institute of Technology