david.cooper at genworks.com
Sat Jan 12 15:23:30 PST 2013
On Sat, Jan 12, 2013 at 2:58 PM, Robert Goldman <rpgoldman at sift.info> wrote:
> "It is recommended that the entire package definition is put in a single
> place, and that all the package definitions of a program are in a single
> file. This file can be loaded before loading or compiling anything else
> that depends on those packages. Such a file can be read in the
> COMMON-LISP-USER package, avoiding any initial state issues."
Thank you for bringing this up. In our system (
http://github.com/genworks/Genworks-GDL) we have several package
redefinitions during the bootstrapping process, which have caused confusion
from time to time. I thought I was being clever and "modular" by redefining
packages when various modules are loaded (exporting new symbols, etc).
Now I think I am coming around to the understanding that it's best to
follow this recommendation from the spec, and simply define everything
up-front, package-wise. Just because some functions are not defined yet
does not mean we can't go ahead and define the entire package, reserving
all the symbols ahead of time.
[Not directly relevant to this mailing list] This came to a head recently
when trying to port to ABCL, and it turned out that ABCL's defpackage does
not modify existing packages (at least, it won't honor new symbols being
:export'ed if you call defpackage on an existing package). Nor does the
ANSI spec require that defpackage does any such modifications to existing
packages. So this whole time we have been relying on non-ANSI-standard
behavior in our bootstrapping process! Rather than continuing to complicate
things by making our own fancy define-package which does the package
modification, I think we will just go ahead and put each of our package
definitions in a single place, once and for all, and move on in life.
Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel