A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]

[Robert Goldman]

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.