[asdf-devel] [cclan-list] How to depend on a system optionally?

[james anderson]

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.