On 4/18/10 Apr 18 -10:18 AM, Juan Jose Garcia-Ripoll wrote:
On Sun, Apr 18, 2010 at 4:56 PM, Robert Goldman <rpgoldman@sift.info <mailto:rpgoldman@sift.info>> wrote:
So: what is the intended effect of :ASDF-DEPENDENCIES and :ASDF-OPTIONAL-DEPENDENCIES? At what point in the processing of the DEFSYSTEM are they processed? How do they interact with the processing of other DEFSYSTEM initargs? The answers to these questions should not be left to reading the code.
This depends on the level of implementation we achieve.
Ideally the situation could be such that the loading of dependencies could be delayed until the system is actually used. In other words, load the system definition using the base class, record components, dependencies, etc, Only when the system is actually loaded, compute the dependencies which are present and can be used and change the class using the extensions which are really available.
I was thinking one might do a two-phase process in which the :asdf-dependencies (and proposed :asdf-optional-dependencies) would be loaded first. Then the remaining defsystem initargs would be processed. Any reason not to do that?
In practice it might not be that simple. There are situations right now in which it might have been useful to load the dependency _before_ even reading the system definition.
Yes, I think that is probably the simplest solution. These situations require further fixes:
- Right now people are using symbols in other packages.
This seems quite undesirable. You can't even /read/ such symbols reliably. Currently this works because the forms that load the asdf dependencies are lexically before the DEFSYSTEM form. But putting the asdf-dependencies there would make this impossible. We would need to find a solution much less cumbersome than the current (funcall (intern <function name> <extension package>) ...) or similar constructs which I find myself typing more often than I'd like in PERFORM methods...