Re: MCL support for MOP

[Vincent Keunen <nrb!keunen@relay.EU.net>]

    Date: Fri, 8 Jan 1993 23:56+0200
    From: bill@cambridge.apple.com (Bill St. Clair)

       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.

Great!  I think this would be very nice.  I believe it is also the
hardest solution out of the 3 (to come up to the same final size).

    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.

If this is very significant, it could help.

    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.

For this to be useful, one needs tools that will tell what library each
function comes from, source analysers,... so that we can decide if each
particular library could be left out without to much work (I mean if I
use only 2 functions from a big library, I can probably rewrite them
differently to keep from using the lib.

    Feedback please. Do you need these facilities? Other ideas?
    The MCL development team has decided that MCL's size is not the
    most important thing we have to work on right now, but it's
    still important to us.

I agree that MCL is much smaller than other lisp environments and still,
is very comfortable (often more).  However, this opens new opportunities
that other environments can't just cope with because of the resources
needed (lisp on unix,...).  So let's not compare too much MCL with other
lisps on other machines.

For the moment, the size required by MCL forces it to be focused on
big/difficult projects.  (don't forget the big cognitive load associated
with CL).  I think that having a way to reduce MCL runtimes
(applications generated by MCL) under 1 meg would open the door to many
more possibilities.  People usually start small and then grow bigger.
And if you start small and get a 2meg app, you don't feel well (even if
it will not grow as much after).  

There was a small app I wanted to develop: I connect to my bank to make
payments and the like.  I always keep a log of all transactions.  I
wanted to develop a small app that would parse the log file (very easy
in lisp), build a database of all transactions (thank you clos) and then
do some inferencing to cross-check various things.  I would have
distributed this app to all the people that use the bank application.
But it would seem a bit foolish to have the bank app at 300Ko and the
"utility to analyse the log file" at 2000Ko!...

I am sure there are lots of utilities that would be very easy to develop
in lisp that don't get developed in C because it's too hard. (think at
all the parsing stuff, rules based stuff, dynamic OO,...).  However,
when you get a 300Ko app or a 2000Ko one, you don't care how much time
the developer spent on it.  You just say the second one is too big EVEN
if it has more features than the other one...

To sum up:  yes MCL is small.  But if it were smaller, it would open
many more opportunities.

I am still in love with MCL. Be tough with your lovers.

Vincent
--
Never trust a pretty header: use keunen@nrb.be to reply
--
Keunen Vincent                  Network Research Belgium
R&D, Software Engineer          Parc Industriel des Hauts-Sarts
keunen@nrb.be                   2e Avenue, 65
tel: +32 41 407282              B-4040 Herstal
fax: +32 41 481170              Belgium