Re: Wish list for next MCL

[miller@cs.rochester.edu (Brad Miller)]

In article <931022171224_76557.704_BHA25-1@CompuServe.COM> 76557.704@CompuServe.COM (Dave Lucky) writes:

> One big wish:  smaller executables.  I'd love to be able to deliver Mac apps in
> MCL where I now have to use C++ because of size.

I concur; seems to me a reasonable tree-shaker, etc. should be able to
get executables down to at least shouting distance from roughly
equivalent C/MacApp code. Esp. if all consing is Dynamic-Extent, or
otherwise has no need for gc, and other special features (perhaps by
declaration, e.g. leave-out-the-condition-system-and-drop-into-macsbug
:-).

Admitably, this is a hard problem, and nobody else does a good job of
it either. But if the canonical hello-world problem could be solved in
256k or less executable, it would be a lot easier to write applications
that are expected to run together.

An easier solution to this problem from my perspective, however, might
just be to include multiprocessing facilities, i.e. stack groups. At
least then I'd be able to allow the user to generate as many processes
as she likes with the overhead already paid. That's a steep price for
the first process, but by the time you are up to 7 or 8 (which is
typical for the app I'm developing), you'd probably be at least
break-even. Sort of like the theory behind putting so much code into
ROM; you may as well allow all your applications to share the lisp
world.

That doesn't help much for those delivering non-multiprocessing
applications, of course, I'm simply recommending that at least part of
the universe will be covered by something that's easier to do than a
lisp super-compiler/application-generator. 

Of course, a *good* VM system for the mac would solve size problems too
(though not address other good reasons to support multiprocessing,
which I won't go into here), but I doubt the good folks in Cambridge
have much control over that.  Perhaps Pink/Taligent/?? will address
that issue?

My personal opinion is that some sort of multiprocessing facilities
should have been part of ANSI common lisp (given the current scope of
the langauge anyway); given that it isn't, I hope vendors will
cooperate in both providing appropriate facilities, and taking care
that they are reasonably compatible with each other (for portablity
reasons).

Just some off-the-cuff-remarks-when-I-should-be-out-drinking,
Brad Miller

-- 
---- Brad Miller miller@cs.rochester.edu
Disclaimer: I disavow any support, or consent for the actions
            or existance of any so called government entity.