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

[Stelian Ionescu]

> 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.


> 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.


> 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.

> 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 ?


> 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".

 
> 4. backwards compatibility involves nothing more than adding a
> LOAD-SYSTEM form to the top of a file.

This breaks one of the most important use cases: doing large scale static analysis of dependencies, like in the case of Quicklisp. At the moment, one cannot even be sure of parsing a .asd without compiling code, unless using a custom reader and/or regular expressions.


> 5. DEFSYSTEM-DEPENDS-ON as introspection will persist, so that
> introspection continues to be supported.

I'm not sure what you mean by this.


> 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.

I think I showed how it can be improved without removing it. Killing it would be a disaster for those who rely on it.


> Alternative: if you, or someone else, will take over ASDF
> maintainership, you can keep DEFSYSTEM-DEPENDS-ON.  I will happily leave
> it to you!

I'm considering this.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.