On 4/6/2011 1:12 PM, Daniel Weinreb wrote:
In large Lisp systems, it's easy to run into problems with the order in which files are loaded and compiled.
One often-vexing issue is where to put package declarations. If a file names an exported symbol such as foo:bar, the package foo with its export list must have been loaded earlier.
In general, it seems to me that in a big complicated system with lots of packages, it would be great if you could just first load all the files with defpackage forms, and get all those packages created and all the external variables externalized, and then load everything else.
However, in a situation I'm working on now, that doesn't work, because package X has (:import-from :y :a1 :a2), and the symbols :a1 and :a2 are not exported from :y. That is, X is exporting internal symbols of Y. This fails, because the symbols :a1 and :a2 do not exist, because they get created only when the files that define them get loaded. So doing all the package declarations first does not work.
Possible approaches:
(1) Too bad; you really do have to load the Lisp files that created those internal symbols after defining package X and before defining package Y.
(2) For Y to export symbols of X that X does not export, while being valid Common Lisp, is a bad practice.
It's a little hard to explain why we're doing this at all. I think it is historical. Originally there was only package X. Then it was considered a good idea to classify some of the functions in package X under a new package name, Y, to make the rest of the code clearer. Unfortunately, the symbols and functions and macros of package X may be too entangled to separate them out the way we would have done had the partition between X and Y been done from the beginning.
By "too hard" I mean that it's not worth the trouble to attain the goal, which was to remove a single ugly use of "::".
But I'm interested in the topic anyway.
As Einstein said, "Make everything as simple as possible, but no simpler." In this case, we begin from admittedly badly-factored code, so I do not find it interesting at all that the package system cannot unravel things for us. Indeed, with Einstein, I would be offended if it /did/ offer an elegant way out.
The only value I see in packages is in cases like this, in which the package system forces one to factor ones code correctly to make it happy. ie, The package system is an artificial and unwitting arbiter of clean code.
kt