Re: [asdf-devel] [cclan-list] How to depend on a system optionally?
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote:
I've read several times that it's a head ache to configure optional dependencies with ASDF.
How true is that? Could we perhaps provide another clause :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system only if available?
Doesn't :WEAKLY-DEPENDS-ON do what you want? Cheers, -- Nikodemus
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote:
I've read several times that it's a head ache to configure optional dependencies with ASDF.
How true is that? Could we perhaps provide another clause :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system only if available?
Doesn't :WEAKLY-DEPENDS-ON do what you want?
there is at least one more kind of dependency between two components: "contingency". simple dependency intends this behaviour: component status component a component/feature b effect expression a (:depends-on (:b)) present present (operate b), (operate a) a (:depends-on (:b)) present absent error a (:depends-on (:b)) absent present error a (:depends-on (:b)) absent absent error given the code in parse-component-form, :weakly-depends-on would appear to effect this behaviour: component status component a component/feature b effect expression a (:weakly-depends-on (:b)) present present (operate b), (operate a) a (:weakly-depends-on (:b)) present absent (operate a) a (:weakly-depends-on (:b)) absent present error a (:weakly-depends-on (:b)) absent absent error there are cases, where it is useful to cause a different behaviour: component status component a component/feature b effect expression a (:contingent-on (:b)) present present (operate a) a (:contingent-on (:b)) present absent a (:contingent-on (:b)) absent present error a (:contingent-on (:b)) absent absent error perhaps there are others. this one is useful when building a system where the components depend on the on the runtime and/or o/s.
james anderson wrote:
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote:
I've read several times that it's a head ache to configure optional dependencies with ASDF.
How true is that? Could we perhaps provide another clause :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system only if available? Doesn't :WEAKLY-DEPENDS-ON do what you want?
there is at least one more kind of dependency between two components: "contingency".
... Did this discussion ever go anywhere? James, would it be possible for you to resend this email with the tables given as a text attachment, rather than as inline text? I don't know about the rest of the list, but my client (Thunderbird) turned your tables into complete and utter gibberish. Best, r
On 2009-07-20, at 21:10 , Robert Goldman wrote:
james anderson wrote:
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote:
I've read several times that it's a head ache to configure optional dependencies with ASDF.
How true is that? Could we perhaps provide another clause :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system only if available? Doesn't :WEAKLY-DEPENDS-ON do what you want?
there is at least one more kind of dependency between two components: "contingency".
...
Did this discussion ever go anywhere?
James, would it be possible for you to resend this email with the tables given as a text attachment, rather than as inline text? I don't know about the rest of the list, but my client (Thunderbird) turned your tables into complete and utter gibberish.
[i suspect it was because i neglected to disable line-wrapping before i sent the message.] to summarize: in addition to simple and weak dependency, there is at least one more kind of dependency between two components: "contingency". in order to manage a system for multiple runtimes, each of which entails it's own foreign libraries, i have found it useful to add a constraint called "contingent-on". this may-or-may-not be what you intend with "optionally-depend-on". i have found it useful to express the constraints: "if a feature|system 'X' is present, then system|component 'Y' is required, and depends on 'X'. if 'X' is not present, do nothing." i attach an html file which describes, as a table, the relation between system model state and operations.
james anderson wrote:
On 2009-07-20, at 21:10 , Robert Goldman wrote:
james anderson wrote:
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote:
I've read several times that it's a head ache to configure optional dependencies with ASDF.
How true is that? Could we perhaps provide another clause :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system only if available? Doesn't :WEAKLY-DEPENDS-ON do what you want?
there is at least one more kind of dependency between two components: "contingency".
...
Did this discussion ever go anywhere?
James, would it be possible for you to resend this email with the tables given as a text attachment, rather than as inline text? I don't know about the rest of the list, but my client (Thunderbird) turned your tables into complete and utter gibberish.
[i suspect it was because i neglected to disable line-wrapping before i sent the message.]
to summarize:
in addition to simple and weak dependency, there is at least one more kind of dependency between two components: "contingency".
in order to manage a system for multiple runtimes, each of which entails it's own foreign libraries, i have found it useful to add a constraint called "contingent-on". this may-or-may-not be what you intend with "optionally-depend-on". i have found it useful to express the constraints:
"if a feature|system 'X' is present, then system|component 'Y' is required, and depends on 'X'. if 'X' is not present, do nothing."
i attach an html file which describes, as a table, the relation between system model state and operations.
I suppose you could kludge this into place, in much the way weakly-depends-on was kludged. Just check the dependency eagerly (at read time), and if the contingency isn't satisfied, prune the component. Note that I have an icky feeling about both of these extensions to ASDF. At the system level, they behave reasonably, but at the module or file level, I think they have weird semantics. What would it mean, for example, to be :contingent-on or :weakly-depend on a :file? Unfortunately, :weakly-depend-on can be parsed off an arbitrary component, not just a system. Oh. Looking at the source, I see that weakly-depends on only works on a system name. This means that (defsystem foobar :weakly-depends-on ((feature "foo")) is not permitted, which seems wrong. That is, it seems wrong until you realize that the feature would be interpreted at the time the defsystem form is READ, not at the time you try to operate on the system. The more I think about this, the more queasy it makes me feel...
------------------------------------------------------------------------
------------------------------------------------------------------------
simple dependency intends this behaviour: component status effect expression component a component/feature b a (:depends-on (:b)) present present (operate b), (operate a) a (:depends-on (:b)) present absent error a (:depends-on (:b)) absent present error a (:depends-on (:b)) absent absent error
------------------------------------------------------------------------
given the code in parse-component-form, :weakly-depends-on would appear to effect this behaviour: component status effect expression component a component/feature b a (:weakly-depends-on (:b)) present present (operate b), (operate a) a (:weakly-depends-on (:b)) present absent (operate a) a (:weakly-depends-on (:b)) absent present error a (:weakly-depends-on (:b)) absent absent error
------------------------------------------------------------------------
there are cases, where it is useful to cause a third behaviour: component status effect expression component a component/feature b a (:contingent-on (:b)) present present (operate b), (operate a) a (:contingent-on (:b)) present absent a (:contingent-on (:b)) absent present error a (:contingent-on (:b)) absent absent error
------------------------------------------------------------------------
perhaps there are others. this one is useful when building a system where the components are contingent on the runtime and/or o/s.
------------------------------------------------------------------------
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
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.
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.
That sounds like a good idea, modulo it would be great to put it in some new section like "TODO list" or "Missing bits in implementation." How about pushing my documentation of weakly-depends-on at the same time? Possibly with some warning that the implementation of this may change. Suggestion: instead of using a trick to get the square peg :weakly-depends on logic to sorta fit in the round-hole :depends-on slot, which forces us to (inappropriately, IMO) evaluate this stuff at macroexpansion time, I think we should suck it up and add extra slots for weak dependencies and contingent dependencies. 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? Extra bonus follow-on: are these expected to be meaningful when the depended-on item is a system (clearly yes), a feature (seems handy), an arbitrary component (what would this mean?)? Best, r
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)))
Extra bonus follow-on: are these expected to be meaningful when the depended-on item is a system (clearly yes), a feature (seems handy), an arbitrary component (what would this mean?)?
i have used contingent dependencies for all of them. eg. if a graphics system is to be built somewhere where clx makes sense, then there is a system dependency between the graphics package and clx. in addition, there is a file-level dependency between the clx-based implementation of rendering operators and clx's presence. one _can_ express everything in terms of #+, but not as clearly.
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? We probably need to examine the 2^3 combinations here and figure out what we intend.
Extra bonus follow-on: are these expected to be meaningful when the depended-on item is a system (clearly yes), a feature (seems handy), an arbitrary component (what would this mean?)?
i have used contingent dependencies for all of them.
The current implementation of weakly-depends-on does not work for anything but a system.
eg. if a graphics system is to be built somewhere where clx makes sense, then there is a system dependency between the graphics package and clx. in addition, there is a file-level dependency between the clx-based implementation of rendering operators and clx's presence.
one _can_ express everything in terms of #+, but not as clearly.
#+ has different semantics, at least in the asdf-file than your contingent-on, because the former is resolved more eagerly.... Best, r
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.
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 will do this.
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.
This is done.
That sounds like a good idea, modulo it would be great to put it in some new section like "TODO list" or "Missing bits in implementation."
How about pushing my documentation of weakly-depends-on at the same time? Possibly with some warning that the implementation of this may change.
Suggestion: instead of using a trick to get the square peg :weakly-depends on logic to sorta fit in the round-hole :depends-on slot, which forces us to (inappropriately, IMO) evaluate this stuff at macroexpansion time, I think we should suck it up and add extra slots for weak dependencies and contingent dependencies.
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?
Extra bonus follow-on: are these expected to be meaningful when the depended-on item is a system (clearly yes), a feature (seems handy), an arbitrary component (what would this mean?)?
Best, r
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM * gwking on twitter
On 2009-07-21, at 00:35 , Robert Goldman wrote:
james anderson wrote:
On 2009-07-20, at 21:10 , Robert Goldman wrote:
james anderson wrote:
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>:
Tobias C. Rittweiler wrote: > I've read several times that it's a head ache to configure > optional > dependencies with ASDF. > > How true is that? Could we perhaps provide another clause > :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system > only if > available? Doesn't :WEAKLY-DEPENDS-ON do what you want?
there is at least one more kind of dependency between two components: "contingency".
...
Did this discussion ever go anywhere?
James, would it be possible for you to resend this email with the tables given as a text attachment, rather than as inline text? I don't know about the rest of the list, but my client (Thunderbird) turned your tables into complete and utter gibberish.
[i suspect it was because i neglected to disable line-wrapping before i sent the message.]
to summarize:
in addition to simple and weak dependency, there is at least one more kind of dependency between two components: "contingency".
in order to manage a system for multiple runtimes, each of which entails it's own foreign libraries, i have found it useful to add a constraint called "contingent-on". this may-or-may-not be what you intend with "optionally-depend-on". i have found it useful to express the constraints:
"if a feature|system 'X' is present, then system|component 'Y' is required, and depends on 'X'. if 'X' is not present, do nothing."
i attach an html file which describes, as a table, the relation between system model state and operations.
I suppose you could kludge this into place, in much the way weakly-depends-on was kludged. Just check the dependency eagerly (at read time), and if the contingency isn't satisfied, prune the component.
i wrote it into the walker. if the contingency is not satisfied, then the component does not exist
Note that I have an icky feeling about both of these extensions to ASDF. At the system level, they behave reasonably, but at the module or file level, I think they have weird semantics.
my recollection is that is has the same semantics at all levels. at least, i don't recall treating any case differently. if you are skeptical, i could pull the instances out of the system files.
What would it mean, for example, to be :contingent-on or :weakly-depend on a :file?
if the file is present, then the contingent component is included in the system and dependent on that file. no different than a simple dependency. the only difference are in the effective behaviour of operate. in my case it makes it possible to do things like include a ffi interface iff dependent on runtime conditionalization and include a particular aspect of the higher level interface iff the particular ffi interface is there.
Unfortunately, :weakly-depend-on can be parsed off an arbitrary component, not just a system. Oh. Looking at the source, I see that weakly-depends on only works on a system name. This means that
(defsystem foobar :weakly-depends-on ((feature "foo"))
is not permitted, which seems wrong. That is, it seems wrong until you realize that the feature would be interpreted at the time the defsystem form is READ, not at the time you try to operate on the system.
The more I think about this, the more queasy it makes me feel...
it's an argument to re-implement it correctly - that is with a uniform semantics
--------------------------------------------------------------------- ---
--------------------------------------------------------------------- ---
simple dependency intends this behaviour: component status effect expression component a component/feature b a (:depends-on (:b)) present present (operate b), (operate a) a (:depends-on (:b)) present absent error a (:depends-on (:b)) absent present error a (:depends-on (:b)) absent absent error
--------------------------------------------------------------------- ---
given the code in parse-component-form, :weakly-depends-on would appear to effect this behaviour: component status effect expression component a component/feature b a (:weakly-depends-on (:b)) present present (operate b), (operate a) a (:weakly-depends-on (:b)) present absent (operate a) a (:weakly-depends-on (:b)) absent present error a (:weakly-depends-on (:b)) absent absent error
--------------------------------------------------------------------- ---
there are cases, where it is useful to cause a third behaviour: component status effect expression component a component/feature b a (:contingent-on (:b)) present present (operate b), (operate a) a (:contingent-on (:b)) present absent a (:contingent-on (:b)) absent present error a (:contingent-on (:b)) absent absent error
--------------------------------------------------------------------- ---
perhaps there are others. this one is useful when building a system where the components are contingent on the runtime and/or o/s.
--------------------------------------------------------------------- ---
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
james anderson wrote:
On 2009-07-21, at 00:35 , Robert Goldman wrote:
james anderson wrote:
On 2009-07-20, at 21:10 , Robert Goldman wrote:
james anderson wrote:
On 2009-05-18, at 14:55 , Nikodemus Siivola wrote:
2009/5/18 Robert Goldman <rpgoldman@sift.info>: > Tobias C. Rittweiler wrote: >> I've read several times that it's a head ache to configure >> optional >> dependencies with ASDF. >> >> How true is that? Could we perhaps provide another clause >> :OPTIONALLY-DEPEND-ON in DEFSYSTEM which would load a system >> only if >> available? Doesn't :WEAKLY-DEPENDS-ON do what you want? there is at least one more kind of dependency between two components: "contingency". ...
Did this discussion ever go anywhere?
James, would it be possible for you to resend this email with the tables given as a text attachment, rather than as inline text? I don't know about the rest of the list, but my client (Thunderbird) turned your tables into complete and utter gibberish. [i suspect it was because i neglected to disable line-wrapping before i sent the message.]
to summarize:
in addition to simple and weak dependency, there is at least one more kind of dependency between two components: "contingency".
in order to manage a system for multiple runtimes, each of which entails it's own foreign libraries, i have found it useful to add a constraint called "contingent-on". this may-or-may-not be what you intend with "optionally-depend-on". i have found it useful to express the constraints:
"if a feature|system 'X' is present, then system|component 'Y' is required, and depends on 'X'. if 'X' is not present, do nothing."
i attach an html file which describes, as a table, the relation between system model state and operations. I suppose you could kludge this into place, in much the way weakly-depends-on was kludged. Just check the dependency eagerly (at read time), and if the contingency isn't satisfied, prune the component.
i wrote it into the walker. if the contingency is not satisfied, then the component does not exist
Note that I have an icky feeling about both of these extensions to ASDF. At the system level, they behave reasonably, but at the module or file level, I think they have weird semantics.
my recollection is that is has the same semantics at all levels. at least, i don't recall treating any case differently. if you are skeptical, i could pull the instances out of the system files.
What would it mean, for example, to be :contingent-on or :weakly-depend on a :file?
if the file is present, then the contingent component is included in the system and dependent on that file. no different than a simple dependency. the only difference are in the effective behaviour of operate. in my case it makes it possible to do things like include a ffi interface iff dependent on runtime conditionalization and include a particular aspect of the higher level interface iff the particular ffi interface is there.
I don't believe that is correct. If you look at the source, weakly-depends-on is not handled as a first class citizen, the way :depends-on is. :depends-on is squirreled away in a slot, and then manipulated at the time we carry out an ASDF operation. The WEAKLY part of :weakly-depends-on, on the other hand (1) only works when the dependency is on a system, not a feature or a file and (2) is resolved when the defsystem is "parsed". I.e., there's no way you can load a system that has weakly-depends on, THEN define another system on which it weakly depends, and have the first system do anything reasonable. The :weakly-depends-on is gone by the time the second system is introduced to your lisp image.
Unfortunately, :weakly-depend-on can be parsed off an arbitrary component, not just a system. Oh. Looking at the source, I see that weakly-depends on only works on a system name. This means that
(defsystem foobar :weakly-depends-on ((feature "foo"))
is not permitted, which seems wrong. That is, it seems wrong until you realize that the feature would be interpreted at the time the defsystem form is READ, not at the time you try to operate on the system.
The more I think about this, the more queasy it makes me feel...
it's an argument to re-implement it correctly - that is with a uniform semantics
Yes, I agree. This should be redone properly. In the meantime, I am inclined to think I should rewrite my weakly-depends-on documentation to explain the irregularities that are hidden there. Best, r
On 2009-07-21, at 01:18 , Robert Goldman wrote:
james anderson wrote:
On 2009-07-21, at 00:35 , Robert Goldman wrote: [...]
What would it mean, for example, to be :contingent-on or :weakly-depend on a :file?
if the file is present, then the contingent component is included in the system and dependent on that file. no different than a simple dependency. the only difference are in the effective behaviour of operate. in my case it makes it possible to do things like include a ffi interface iff dependent on runtime conditionalization and include a particular aspect of the higher level interface iff the particular ffi interface is there.
I don't believe that is correct.
? in that weakly-depends-on does not do this, or this is not a "correct" thing to do? i do not use weakly-depends-on. i implemented :contingent-on.
If you look at the source, weakly-depends-on is not handled as a first class citizen, the way :depends-on is. :depends-on is squirreled away in a slot, and then manipulated at the time we carry out an ASDF operation. The WEAKLY part of :weakly-depends-on, on the other hand (1) only works when the dependency is on a system, not a feature or a file and (2) is resolved when the defsystem is "parsed". I.e., there's no way you can load a system that has weakly-depends on, THEN define another system on which it weakly depends, and have the first system do anything reasonable. The :weakly-depends-on is gone by the time the second system is introduced to your lisp image.
weakly depends on may well not be well implemented. i do not use it.
Unfortunately, :weakly-depend-on can be parsed off an arbitrary component, not just a system. Oh. Looking at the source, I see that weakly-depends on only works on a system name. This means that
(defsystem foobar :weakly-depends-on ((feature "foo"))
is not permitted, which seems wrong. That is, it seems wrong until you realize that the feature would be interpreted at the time the defsystem form is READ, not at the time you try to operate on the system.
The more I think about this, the more queasy it makes me feel...
it's an argument to re-implement it correctly - that is with a uniform semantics
Yes, I agree. This should be redone properly.
In the meantime, I am inclined to think I should rewrite my weakly-depends-on documentation to explain the irregularities that are hidden there.
Best, r
james anderson wrote:
On 2009-07-21, at 01:18 , Robert Goldman wrote:
james anderson wrote:
What would it mean, for example, to be :contingent-on or :weakly-depend on a :file? if the file is present, then the contingent component is included in
On 2009-07-21, at 00:35 , Robert Goldman wrote: [...] the system and dependent on that file. no different than a simple dependency. the only difference are in the effective behaviour of operate. in my case it makes it possible to do things like include a ffi interface iff dependent on runtime conditionalization and include a particular aspect of the higher level interface iff the particular ffi interface is there. I don't believe that is correct.
? in that weakly-depends-on does not do this, or this is not a "correct" thing to do?
The former. weakly-depends-on does not do these sophisticated things.
i do not use weakly-depends-on. i implemented :contingent-on.
If you look at the source, weakly-depends-on is not handled as a first class citizen, the way :depends-on is. :depends-on is squirreled away in a slot, and then manipulated at the time we carry out an ASDF operation. The WEAKLY part of :weakly-depends-on, on the other hand (1) only works when the dependency is on a system, not a feature or a file and (2) is resolved when the defsystem is "parsed". I.e., there's no way you can load a system that has weakly-depends on, THEN define another system on which it weakly depends, and have the first system do anything reasonable. The :weakly-depends-on is gone by the time the second system is introduced to your lisp image.
weakly depends on may well not be well implemented. i do not use it.
Yes, that's my point. I'd rather it not become widely used, lest it become another oddity with which we must maintain backward compatibility.
participants (4)
-
Gary King -
james anderson -
Nikodemus Siivola -
Robert Goldman