[asdf-devel] [cclan-list] How to depend on a system optionally?
james.anderson at setf.de
Tue Jul 21 00:16:29 UTC 2009
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
>>>> 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
>> (:file "b-ffi" (:contingent-on
>> "linux" :sbcl))
>> (:file "b-inter" (:contingent-on
>> (: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
> 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
> 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-
there are two distinct aspects
- the conditional presence of a component is contingency.
- the conditional presence of a relation between two components is
of which, the first one dominates.
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
if any weak dependencies are defined, they are examined and those for
which the preconditions are satisified are treated as if they are
the strong dependencies are interpreted.
yes, this does mean that there are definite deficiencies in the
current implementation of weak dependency.
More information about the asdf-devel