Re: [asdf-devel] Feature-conditional components
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___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
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 ___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
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___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
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 ___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
On 22 October 2010 16:23, Robert Goldman 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 ___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
On 10/22/10 Oct 22 -7:11 AM, Nikodemus Siivola wrote: > On 22 October 2010 05:19, Faré 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 ___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Re: [asdf-devel] Feature-conditional components
On 22 October 2010 05:19, Faré 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 ___ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
