On 2009-07-21, at 01:39 , Robert Goldman wrote:
james anderson wrote:
On 2009-07-21, at 00:58 , Robert Goldman wrote:
Gary King wrote:
I share Robert's queasiness and also think that we want ASDF to support these sorts of dependencies (simple, weak, contingent, etc... (?)).
I'm going to update the manual with James's table (thanks James!) in the hopes of giving us a place to hang our collective hats.
[...]
Follow-on suggestion: we need to think about what happens when a component has all possible combinations of :depends-on, :weakly-depends-on, and :contingent-on. Does something that would not be loaded because of :contingent-on avoid a crash that would come from a violated :depends-on?
hmmm... depends on what you mean by a "crash". it probably does not make sense to define a relation like
(:file "a" (:contingent-on :osx)) (:file "b" (:depends-on "a"))
as that reads as if that "a" will always be present, which is likely to cause confusion if the statements are not _real_ close neighbors in the system description.
what does make sense is
(:module "x" (:components ((:module :ffi (:components ((:file "a-ffi" (:contingent-on "osx" :ccl)) (:file "a-inter" (:contingent-on "a- ffi")) (:file "b-ffi" (:contingent-on "linux" :sbcl)) (:file "b-inter" (:contingent-on "b- ffi"))))) (:file "x-ops" (:depends-on :ffi)))
What about
(:file "foobar (:contingent-on (feature :macosx)) (:weakly-depends-on (another-system)) (:depends-on ("a-file")))
It seems like we'd want the :depends-on not to cause an error when traversing the system if the :contingent-on fails....
What if the weakly-depends-on thing is supposed to establish the feature we are contingent on?
need not be weakly dependent, strongly exhibits the same problem. #+ would exhibit the equivalent problem. the feature state must be established before it is interpreted. in the contingency case, at the the "point of binding" is delayed as far as possible. in principle, such a system definition is suspect and the dependency should be expressed better. instead of being between one component and a side-effect of operating on another component, it should be between the respective components. in my example, i expressed such a relationship as a contingency between both the system as-a-whole and one of its files upon some other system.
We probably need to examine the 2^3 combinations here and figure out what we intend.
i do not see the combinatorial implications. the logic is straight- forward. there are two distinct aspects - the conditional presence of a component is contingency. - the conditional presence of a relation between two components is weak dependence. of which, the first one dominates.
first: if a contingency is specified, then if it is satisfied, then the component is to be operated upon. if the contingency is not satisfied, then the component is to be treated as if it is not present in the system. [which means, it should be an error to have a strong dependency on it]
next: if any weak dependencies are defined, they are examined and those for which the preconditions are satisified are treated as if they are strong.
last: the strong dependencies are interpreted.
yes, this does mean that there are definite deficiencies in the current implementation of weak dependency.