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