The latest version of ASDF contains three functions:
SYSTEM-DEFSYSTEM-DEPENDS-ON SYSTEM-DEPENDS-ON and SYSTEM-WEAKLY-DEPENDS-ON
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.
R
On Fri, Feb 21, 2014 at 3:46 PM, Robert P. Goldman rpgoldman@sift.info wrote:
The latest version of ASDF contains three functions:
SYSTEM-DEFSYSTEM-DEPENDS-ON SYSTEM-DEPENDS-ON and SYSTEM-WEAKLY-DEPENDS-ON
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)
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The greatest productive force is human selfishness. — Robert Heinlein, "Time Enough For Love"
Faré wrote:
On Fri, Feb 21, 2014 at 3:46 PM, Robert P. Goldman rpgoldman@sift.info wrote:
The latest version of ASDF contains three functions:
SYSTEM-DEFSYSTEM-DEPENDS-ON SYSTEM-DEPENDS-ON and SYSTEM-WEAKLY-DEPENDS-ON
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.
cheers, r
This resolve-dependency-spec returns the actual system objects for depended on systems, doesn't it? Hence the possible side effects.
Yes.
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.
You could do that in the common case, I suppose, but the user would still have to call resolve-dependency-spec in the general case, since the protocol is extensible. Making it appear like the name has been resolved when it hasn't been is probably a lure that will invite people to do the wrong thing and get bitten — more efforts for negative return on investment.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Informal "design patterns" are the crutch of inexpressive programming systems. In a programmable programming system, the only design pattern needed is: use the system to refine and extend the system.
Faré wrote:
This resolve-dependency-spec returns the actual system objects for depended on systems, doesn't it? Hence the possible side effects.
Yes.
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.
You could do that in the common case, I suppose, but the user would still have to call resolve-dependency-spec in the general case, since the protocol is extensible. Making it appear like the name has been resolved when it hasn't been is probably a lure that will invite people to do the wrong thing and get bitten — more efforts for negative return on investment.
Hmmmm.... The thing I don't like is to have some large number of half-baked bits of code that all do some buggy bit of tree recursion to make sure that they recognize that
:depends-on (foo) ; foo in some package :depends-on ("foo") ; string :depends-on (:foo)
are all the same thing. Failing to do that for the caller seems like we are providing a bad API.
I figured since "foo" is the internal form, (list "foo") should be the return for all three of the above cases.
If you call resolve-dependency-spec on
:weakly-depends-on (:blort)
when blort isn't present, don't we get a bad result that foils the intent of using system-weakly-depends-on as an introspection tool?
Thanks, r
I just felt like fixing this in ASDF would be better than requiring the caller to do it.
You could do that in the common case, I suppose, but the user would still have to call resolve-dependency-spec in the general case, since the protocol is extensible. Making it appear like the name has been resolved when it hasn't been is probably a lure that will invite people to do the wrong thing and get bitten — more efforts for negative return on investment.
Hmmmm.... The thing I don't like is to have some large number of half-baked bits of code that all do some buggy bit of tree recursion to make sure that they recognize that
:depends-on (foo) ; foo in some package :depends-on ("foo") ; string :depends-on (:foo)
are all the same thing. Failing to do that for the caller seems like we are providing a bad API.
I figured since "foo" is the internal form, (list "foo") should be the return for all three of the above cases.
If you call resolve-dependency-spec on
:weakly-depends-on (:blort)
when blort isn't present, don't we get a bad result that foils the intent of using system-weakly-depends-on as an introspection tool?
The user should use the same API as parse-component-form. And that's where I see that the way it filters weakly-depends-on is buggy, since it calls find-system and not resolve-dependency-spec. At this point, either it should call it and somehow catch a condition when the component is missing (but what if it's an indirect component while loading a .asd that raises the condition? This sucks — and locate-system won't suffice either for secondary systems), or you're right and we should restrict weakly-depends-on to system names and not generalized specs. In any case, ASDF is currently buggy.
I admit I never liked weakly-depends-on and never gave it much love. My opinion is that's it's an ill-conceived feature that I would never have let in because it doesn't fit my idea of a deterministic build (unless ASDF started to do filesystem versioning and include a hash of the used portion of the filesystem into the name of output files, like I never got around to having XCVB do). In any case, I never got around to either adopting the feature seriously, or seriously deprecating it and expunging it from the CL code base.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org — Question authority! — Yeah, says who?
Faré wrote:
The user should use the same API as parse-component-form. And that's where I see that the way it filters weakly-depends-on is buggy, since it calls find-system and not resolve-dependency-spec. At this point, either it should call it and somehow catch a condition when the component is missing (but what if it's an indirect component while loading a .asd that raises the condition? This sucks — and locate-system won't suffice either for secondary systems), or you're right and we should restrict weakly-depends-on to system names and not generalized specs. In any case, ASDF is currently buggy.
Quick follow-up (sorry, lost track of this over many days).
The grammar /does/ specify that weakly-depends-on can only have system names, not general dependency specifications. I have documented the return type of SYSTEM-WEAKLY-DEPENDS-ON accordingly.
Cheers, r
-
Faré -
Robert P. Goldman