[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wade Hennessey's work on lisp
> Date: Wed, 2 Dec 92 13:03:04 -0800
> From: David B. Serafini <firstname.lastname@example.org>
> From: email@example.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.
You can't; symbols can be created and interned or used on the fly.
(eval (read)) is valid common-lisp.