🚀 go-pugleaf

davis@ilog.ILog.FR (Harley Davis) writes:

>I also think there is something indicative in your statement that at a
>certain point you should "crystallize your application by doing a
>DISKSAVE or whatever".  This idea that the state of memory somehow is
>the best representation of your application is deadly in today's
>computing environments.  As I said, we must integrate Lisp into
>existing environments, and one of the fundamental principles of
>program development in traditional OS's is that your code (statically
>known) plus a static program description (eg a Makefile) constitutes
>your application.  If you stray too far from this simple (and
>admittedly frustratingly limited) model, you are bound to end up in
>trouble.  Lisp has fought an uphill battle in the conventional world
>because Lisp program development has been seen as incremental
>modification of the state of the Lisp image.

  Ken was a little to vague saying "DISKSAVE or whatever".  A good
example of the kind of facility that is needed did exist.  DEC had
a resonable commonlisp system (before DEC decided to disband the
lisp group and sell a third party system).  They provided a usefull
extension to common lisp.  Clearly not within the standard, but
very usefull.  They shiped the binaries for the lisp system code,
and included a function that was something between a make and disksave.
It allowed you to build a lisp image that included only the system
functionality you requested, plus your code.  You could leave out the
compiler, debugger; there were many parts that were optional.
It was very similar to Lucid's delivery tool kit but had one big
advantage.  In the resulting image, read-only space was shareable.
All compiled code, and constants, and any data the user explicitly
declared to be read-only, were shared.

  We were running a fairly large system in DECLisp.  It was five
years ago, and I am generating these numbers from memory, so I
could be wrong.  I think our image (with no special treatment)
was around 35 to 40 meg.  After dropping the development environment
(both system code and some of our code) it dropped down to about 25meg
About 80% of that was shareable.  We were running on a microvax II.
Without shareable code, a second user running lisp caused serious
performance problems.  With shareable code, two users could run
comfortably, a third would slow down the system, but not as much
as two non-shared users.

  It is this kind of practical tool that will help make lisp a
viable commercial language.


Gerard Donlon.   (gdonlon@bbn.com)
BBN Systems and Technologies
4015 Hancock St   San Diego, Ca 92110