home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!cs.utexas.edu!sun-barr!olivea!apple!goofy!cambridge.apple.com!oddmund@idt.unit.no
- From: oddmund@idt.unit.no
- Newsgroups: comp.lang.lisp.mcl
- Subject: RE: MCL size/distribution (was: MCL support for MOP)
- Message-ID: <199301101618.AA10128@sigyn.idt.unit.no>
- Date: 10 Jan 93 16:18:38 GMT
- Sender: info-mcl-request@cambridge.apple.com
- Lines: 55
- Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
-
-
- >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
-