[asdf-devel] Feature-conditional components
1- ASDF has no such mechanism yet. Many people have asked for it (at least nikodemus, manic12, and myself recently). 2- the feature feature was never working before I fixed and cerror'ed it, and only does conditional *dependency* on another component, that has to independently exist or conditionally exist, for which we have no non-ugly mechanism. 3- the :if-component-dep-fails mechanism may or may not be working well enough to do that right now, but man it's ugly, non-intuitive, non-documented, and gross even if it were documented. 4- the very structure of ASDF objects doesn't allow a clean way of expressing conditionally-included components, and this can't be added as an extension (at least, not unless ASDF is extended to provide a proper API, anyway). Doing anything more sophisticated than #+foo or :if-component-dep-fails is going to be "interesting" and require major work. 5- XCVB has such a mechanism, and I propose that if ASDF is to adopt non-trivial conditionals, we should import XCVB's mini-language for conditionals, if not the rest of it. 6- Hey - why not develop XCVB some more? Like, port it to your favorite platform? I'd need a bit of help to make standalone backends for Windows, including a committed hacker to port relevant parts of IOLib to Windows. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Invent a clever saying, and your name shall live forever. — Anonymous
On 22 October 2010 05:19, Faré <fahree@gmail.com> wrote:
2- the feature feature was never working before I fixed and cerror'ed it, and only does conditional *dependency* on another component, that has to independently exist or conditionally exist, for which we have no non-ugly mechanism.
3- the :if-component-dep-fails mechanism may or may not be working well enough to do that right now, but man it's ugly, non-intuitive, non-documented, and gross even if it were documented.
Note: I have two different use cases. One is a DEFSYSTEM -level :DEPENDS-on ((FEATURE :SBCL :SB-THREAD)) or similar to indicate what *FEATURES* the system assumes, so that tools like Quicklisp could use this information to good effect. It should be checked during attempts to OPERATE LOAD-OP on system, with an error if the feature is not present, and it should be available through system introspection. The thing that I'm currently using :IF-COMPONENT-DEP-FAILS :TRY-NEXT for currently is (:FILE "sbcl" :IN-ORDER-TO ((COMPILE-OP (FEATURE :SBCL)))) which is quite different. Cheers, -- Nikodemus
On 10/22/10 Oct 22 -7:11 AM, Nikodemus Siivola wrote:
On 22 October 2010 05:19, Faré <fahree@gmail.com> wrote:
2- the feature feature was never working before I fixed and cerror'ed it, and only does conditional *dependency* on another component, that has to independently exist or conditionally exist, for which we have no non-ugly mechanism.
3- the :if-component-dep-fails mechanism may or may not be working well enough to do that right now, but man it's ugly, non-intuitive, non-documented, and gross even if it were documented.
Note: I have two different use cases.
One is a DEFSYSTEM -level :DEPENDS-on ((FEATURE :SBCL :SB-THREAD)) or similar to indicate what *FEATURES* the system assumes, so that tools like Quicklisp could use this information to good effect.
It should be checked during attempts to OPERATE LOAD-OP on system, with an error if the feature is not present, and it should be available through system introspection.
Question: in the above, are you assuming implicit conjunction, so that this is intended to be synonymous with :depends-on ((FEATURE :SBCL) (FEATURE :SB-THREAD)) ? Do we need to support /disjunction/ as well? E.g., :depends-on ((OR (FEATURE :SBCL :SB-THREAD) (FEATURE :ALLEGRO :SOME-ALLEGRO-THREADING-THING))) or even implication? Let's assume, for example, that allegro has threading always, but SBCL not so: :depends-on ((IMPLIES (FEATURE :SBCL) (FEATURE :SB-THREAD))) Will this cause problems for the defsystem parser? Features are symbols and must be parsed as such, rather than down-cased strings like component names. It won't be rocket science to get that right, but we should keep it in mind. Another question: should we push this into an ASDF 2.1? That way people can do something like (defsystem .... :depends-on (#+ASDF2.1 (feature :sbcl :sb-thread) ...other dependencies...) since this is really a pretty substantial change to the API, and programmers need to be able to detect whether the ASDF is able to handle it. or possibly add :asdf-feature-dependencies to *features* when loading an ASDF that can handle these. I hope this doesn't seem like fussiness, but I'd rather get this functionality right than have to do it over, possibly messing with people who've started using it. And maybe this design discussion should be put in a launchpad bug at some point (perhaps digested by someone) so that there's something spec-like to code to. Best, r
On 22 October 2010 16:23, Robert Goldman <rpgoldman@sift.info> wrote:
Do we need to support /disjunction/ as well? E.g.,
:depends-on ((OR (FEATURE :SBCL :SB-THREAD) (FEATURE :ALLEGRO :SOME-ALLEGRO-THREADING-THING)))
or even implication? Let's assume, for example, that allegro has threading always, but SBCL not so:
I think arbitrary feature expressions composed of :OR, :AND, and :NOT -- "just like in the reader" are what I'm after. My initial example should have used ((FEATURE (:AND :SBCL :SB-THREAD))), I guess.
since this is really a pretty substantial change to the API, and programmers need to be able to detect whether the ASDF is able to handle it.
No big opinions on this. Cheers, -- Nikodemus
1- we probably want conditionally included components, as in xcvb: (:when (:featurep (:and :sbcl sb-thread)) (:file "sbcl-threaded-support")) (:when (:featurep (:or :cmu :scl)) (:file "cmucl-support")) 2- is depending on a suppressed component a bug, a nop, or something that forces the component to be un-suppressed? [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "I carry a gun because a cop is too heavy." — R. Lee Wrights
On Fri, 22 Oct 2010, Faré wrote:
2- is depending on a suppressed component a bug, a nop, or something that forces the component to be un-suppressed?
If X depends on Y, and Y has been disabled, then X cannot load properly. Was Y a requirement for X, or just something that should load earlier? If the former, then X should not be allowed to load. If the latter, then there's no issue. If X is not allowed to load, under what circumstances should this cause the operation to fail? Rather than ponder these ambiguities, maybe it would be better to let the user insert errors where they belong, possibly using IF clauses? Then ASDF could adopt the simple rule of proceeding unless told otherwise. - Daniel
On 10/22/10 Oct 22 -11:56 PM, Daniel Herring wrote:
On Fri, 22 Oct 2010, Faré wrote:
2- is depending on a suppressed component a bug, a nop, or something that forces the component to be un-suppressed?
If X depends on Y, and Y has been disabled, then X cannot load properly.
Was Y a requirement for X, or just something that should load earlier? If the former, then X should not be allowed to load. If the latter, then there's no issue.
If X is not allowed to load, under what circumstances should this cause the operation to fail?
Rather than ponder these ambiguities, maybe it would be better to let the user insert errors where they belong, possibly using IF clauses? Then ASDF could adopt the simple rule of proceeding unless told otherwise.
I'm reluctant to see us go down this path. The primary advantage of having feature dependencies, over the #+ mechanism that CL already offers us, is that feature dependencies are declarative and enable introspection. If we let people write programs in feature dependencies, these advantages will go away. Without those advantages, we might as well not complicate ASDF with feature dependencies; we can just let system definers continue to use reader conditionals.... So I'd suggest we define simple policies along the lines that Faré suggests. best, r
On Sun, 24 Oct 2010, Robert Goldman wrote:
On 10/22/10 Oct 22 -11:56 PM, Daniel Herring wrote:
On Fri, 22 Oct 2010, Faré wrote:
2- is depending on a suppressed component a bug, a nop, or something that forces the component to be un-suppressed?
If X depends on Y, and Y has been disabled, then X cannot load properly.
Was Y a requirement for X, or just something that should load earlier? If the former, then X should not be allowed to load. If the latter, then there's no issue.
If X is not allowed to load, under what circumstances should this cause the operation to fail?
Rather than ponder these ambiguities, maybe it would be better to let the user insert errors where they belong, possibly using IF clauses? Then ASDF could adopt the simple rule of proceeding unless told otherwise.
I'm reluctant to see us go down this path.
The primary advantage of having feature dependencies, over the #+ mechanism that CL already offers us, is that feature dependencies are declarative and enable introspection.
And error declarations do not prevent that.
If we let people write programs in feature dependencies, these advantages will go away.
Without those advantages, we might as well not complicate ASDF with feature dependencies; we can just let system definers continue to use reader conditionals....
So I'd suggest we define simple policies along the lines that Faré suggests.
That's find if people can agree on simple, flexible semantics. I made this suggestion because it seemed simple and flexible. C++ has taught me a dislike of coupling separate concepts together (e.g. struct vs class vs namespace). - Daniel
participants (4)
-
Daniel Herring -
Faré -
Nikodemus Siivola -
Robert Goldman