Wade Hennessey's work on lisp

[miller@cs.rochester.edu]

> Date: Wed, 2 Dec 92 13:03:04 -0800
> From: David B. Serafini <serafini@ra-iris.arc.nasa.gov>

>    From: layer@franz.com (Kevin Layer)
>    Date: Wed, 02 Dec 92 10:16:11 -0800

>    >> I picked up Hennessey's paper (described in included message below)
>    >> and found it quite convincing. I'd like to know what people at Franz
>    >> think of this work and if acl is moving in this direction.

>    We have been looking at shared library technology since it was
>    introduced on various platforms, and will be giving more thought to
>    the incorporation of it into a future version of Allegro CL.

>    As you know, there is a trade off between the ability to share
>    portions of an image among many processes and the cost of initializing
>    an image to link in the shared libraries and create the per-process
>    data.  Lisp, unlike C, has a large dynamic component.  For example,
>    the symbols made available by a shared library need to be interned.
>    It is unclear what the startup cost of an executable would be for a
>    fully compliant ANSI Common Lisp (ie, one that includes CLOS).

> But, since the purpose of a shared-library lisp is to reduce application
> size, couldn't you have some kind of compiler/optimizer that would only 
> intern the symbols that were used in the application?  I assmue this would
> radically reduce the number of symbols needed, and maybe make startup 
> faster.  I know this approach has been used to reduce image sizes by 
> removing unneeded code.

> -David

You can't; symbols can be created and interned or used on the fly.
(eval (read)) is valid common-lisp.