On Mon, 2016-02-15 at 11:13 -0600, Robert Goldman wrote: > On 2/15/16 Feb 15 -10:26 AM, Stelian Ionescu wrote: > >> On 2/12/16 Feb 12 -3:15 PM, Stelian Ionescu wrote: > >>> On Fri, 2016-02-12 at 16:07 -0500, Faré wrote: > >>>> I'm OK with declaring DEFSYSTEM-DEPENDS-ON a failure, and load-system > >>>> (or load-systems) the official way to go. But > >>>> > >>>> 1- This of course requires heads up, updating all users before > >>>> retiring the feature, etc. From my experience, if you start seriously > >>>> deprecating today and sending patches to all authors who use it in > >>>> quicklisp, you can expect to be removing that part of the code in two > >>>> years or so. > >>>> > >>>> 2- To make these dependencies work properly still requires modifying > >>>> ASDF to add explicit plan nodes for loading ASD files, that will > >>>> contain the systems loaded by load-system. The same trick will also > >>>> automatically make the :defsystem-depends-on work, since it itself > >>>> calls load-system. > >>>> > >>>> 3- Yes, defining things in the ASDF package is ugly, but extensions > >>>> are few enough, and using a prefix is a good enough namespace > >>>> management strategy. Not the most horrible thing that working with CL > >>>> does to you. > >>> > >>> Please don't. It's a net improvement compared to the previous situation. > >>> It's easy to simply name your class with a keyword :package/foo-file. > >>> > >> > >> With all due respect, no, it is not. It is a net *negative* with > >> respect to the previous situation. Here are the reasons why, briefly > >> reiterated: > >> > >> 1. It effectively forces you to stick new symbols into the ASDF namespace. > > > > Technically yes, but that's not the essential requirement. Because the CL > > reader interns eagerly, ASDF extension classes need to be interned into a > > package that is owned by ASDF. Currently that's the ASDF package itself, > > but it would be a good idea to add a special package for extensions, and > > start encouraging people to use that by showing appropriate deprecation > > messages. > > This doesn't do anything to resolve the underlying problem, AFAICT. > I.e., instead of getting name collisions in ASDF (I believe that's > ASDF/INTERFACE), we get name collisions in ASDF/EXTENSIONS.
I don't see this as a problem. A few times there were collisions in Quicklisp, so somebody had to rename the project/package, etc... If two different authors want to use asdf/extensions::foo/file then one will have to give up. This is a technical problem(the design of the CL reader) that is best solved socially. Also, it's not like people write new ASDF extensions everyday. > > Am I missing something about this suggestion? > > > > > >> I don't understand your proposed rebuttal, involving slash-named > >> packages. I don't see any evidence of this being legal ASDF syntax, > >> looking at FIND-CLASS*, and trying an experiment. If it works, it needs > >> documentation. If it does not work, it will not be added -- ASDF must > >> get simpler, not more complex. Please amplify, thanks! > > > > It's not "syntax", it's just manual namespacing. The symbol > > 'asdf::pkg/class is symply a legal symbol. And I don't agree that ASDF must > > get simpler at all costs, rather that it should have as simple an > > implementation as possible, while still allowing the use cases that its > > users require. > > With all due respect, I believe ASDF to be unmaintainable now, except > for a Hail Mary Pass to Faré at regular intervals. Again, you are > welcome to have a whack at it. I won't be upset if you prove me wrong! > > > > > >> 2. If you are arguing that we can just solve this with a naming > >> convention, I don't buy it. Consider different libraries, each of which > >> hook ASDF to normal "make" by creating MAKE-FILE and MAKE-OP classes. > >> This is not a far-fetched example; I have seen it. They both try to jam > >> these symbols into ASDF. > > > > See my previous reply. > > > > > >> This behavior should be *strongly* discouraged, even to the extent of > >> (as I said earlier) package-locking ASDF when possible. Currently, it > >> is actively *ENCOURAGED* -- close to mandated, in fact. > > > > By dedicating a package for naming extension classes, we can even lock ASDF > > while still making QA easier. > > Per earlier response, this seems to me to just kick the problem from one > namespace/package to another. > > > >> 3. If we make DEFSYSTEM-DEPENDS-ON into a declaration, a lot of > >> simplification ensues, including eliminating the complex double-parsing > >> of DEFSYSTEM. ASDF is currently over-complicated and over-long. > > > > In what sense is it not currently a declaration ? > > What I meant is that it's not *only* a declaration. It has extra > operational import. I would like to change D-D-O to be only > declarative (except that we will also check it). > > > > > > >> 4. The double-parsing doesn't even work, because the packages don't > >> exist at the right time. That's why, even with DEFSYSTEM-DEPENDS-ON, > >> you must either mess with the ASDF package, or put in a LOAD-SYSTEM call > >> to get the symbols created, and stuck into *PACKAGE* before the > >> defsystem form is parsed. > > > > I think this might be an issue with the current implementation of > > DEFSYSTEM-DEPENDS-ON, but that's not a necessity. E.g.: > > > > (defsystem foo > > :defsystem-depends-on (foo/asd) > > :components ((:foo/file "foo"))) > > > > This ought to mean that LOAD-SYSTEM of "foo" depends on LOAD-SYSTEM of > > "foo/asd", and that the exact class object named by "foo/file" should be > > fetched right after loading "foo/asd". > > Fetched from where? Do you want to further extend the syntax so that > FOO/FILE is interpreted as FOO:FILE? That might be feasible (suggest > you try). It would certainly be preferable to adding an ASDF/EXTENSIONS > package and fighting over its contents. No, have it search for a symbol named (string :foo/file) first in ASDF/EXTENSIONS then ASDF, for backwards-compatibility, then one day only ASDF/EXTENSIONS. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
signature.asc
Description: This is a digitally signed message part
