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. 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! 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. 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. 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. 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. 4. backwards compatibility involves nothing more than adding a LOAD-SYSTEM form to the top of a file. 5. DEFSYSTEM-DEPENDS-ON as introspection will persist, so that introspection continues to be supported. TL;DR: We have a "declarative" construct which is not declarative at all. Worse, it almost forces poisonous namespace pollution. Killing it would simplify the code. Minimal backwards-compatibility issues. Alternative: if you, or someone else, will take over ASDF maintainership, you can keep DEFSYSTEM-DEPENDS-ON. I will happily leave it to you! The bottom line: ASDF is way too big for me to wrap my head around, in very limited available time. It has to get simpler. Removing things that don't work is a good start.
