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.