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

[Daniel Kochmański]

Hey,

I just want to say that I strongly support simplification of the
ASDF. It's a great project and solves gazillion of problems, but having
actual specification with some core features would make it way better
for me.

Even if not for this release, the next release might focus on
stabilizing the API and freezing it, because constant evolving isn't the
best thing I could imagine for the de-facto standard.

Best regards,
Daniel Kochmański

Robert Goldman writes:

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

-- 
Daniel Kochmański ;; aka jackdaniel | Poznań, Poland
TurtleWare - Daniel Kochmański      | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi