[asdf-devel] How should ASDF return cached system definition information

Robert P. Goldman rpgoldman at sift.info
Fri Feb 21 21:21:30 UTC 2014

Faré wrote:
> On Fri, Feb 21, 2014 at 3:46 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
>> The latest version of ASDF contains three functions:
>> that return information about defined systems.  The intention is to
>> support introspection about sets of systems (I believe Quicklisp does
>> this today).
>> Currently, ASDF does *not* put the return values into canonical form.
>> So, equivalent forms like
>> :depends-on (foo)
>> and
>> :depends-on ("foo")
>> will yield different return values.
>> Similarly, :version specifications will not be resolved.
>> This seems wrong to me.  I feel that the return values should be
>> canonicalized.  So all system names should be resolved down to
>> lower-cased strings.
>> Does that sound like the right approach?  It would support performing
>> inference on the systems relatively straightforwardly. I can't imagine
>> why people would want the exact, literal slot initforms, but I could be
>> wrong.
> I fear returning the raw data might be the right thing,
> because resolving can have side-effects that the caller may want to control,
> and/or resolve to NIL, etc.
> What is important, however, is to specify in the documentation
> how the entries are to be resolved, namely with
> 	(resolve-dependency-spec component dep-spec)

This resolve-dependency-spec returns the actual system objects for depended on systems, doesn't it?  Hence the possible side effects.

I was thinking of the much simpler expedient of traversing the dependency s-expressions and using COERCE-NAME on all the system names.  That gives us something that is canonical, but that functions when there are missing systems (e.g., this system weakly-depends-on <that>, but <that> isn't present), and is computed without side-effects.

I just felt like fixing this in ASDF would be better than requiring the caller to do it.


More information about the asdf-devel mailing list