[asdf-devel] :ASDF-DEPENDENCIES implemented

Robert Goldman rpgoldman at sift.info
Sun Apr 18 15:24:10 UTC 2010


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 at sift.info
> <mailto:rpgoldman at 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...




More information about the asdf-devel mailing list