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

Mon Feb 15 20:19:09 UTC 2016

On Mon, 2016-02-15 at 11:13 -0600, Robert Goldman wrote:
> On 2/15/16 Feb 15 -10:26 AM, Stelian Ionescu wrote:
> >> 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.
> 
> This doesn't do anything to resolve the underlying problem, AFAICT.
> I.e., instead of getting name collisions in ASDF (I believe that's
> ASDF/INTERFACE), we get name collisions in ASDF/EXTENSIONS.

I don't see this as a problem. A few times there were collisions in
Quicklisp, so somebody had to rename the project/package, etc... If two
different authors want to use asdf/extensions::foo/file then one will
have to give up. This is a technical problem(the design of the CL
reader) that is best solved socially. Also, it's not like people write
new ASDF extensions everyday.

> 
> Am I missing something about this suggestion?
> > 
> > 
> >> 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.
> 
> With all due respect, I believe ASDF to be unmaintainable now, except
> for a Hail Mary Pass to Faré at regular intervals.  Again, you are
> welcome to have a whack at it.  I won't be upset if you prove me wrong!
> > 
> > 
> >> 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.
> 
> Per earlier response, this seems to me to just kick the problem from one
> namespace/package to another.
> > 
> >> 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 ?
> 
> What I meant is that it's not *only* a declaration.  It has extra
> operational import.   I would like to change D-D-O to be only
> declarative (except that we will also check it).
> 
> > 
> > 
> >> 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".
> 
> Fetched from where?  Do you want to further extend the syntax so that
> FOO/FILE is interpreted as FOO:FILE?  That might be feasible (suggest
> you try).  It would certainly be preferable to adding an ASDF/EXTENSIONS
> package and fighting over its contents.

No, have it search for a symbol named (string :foo/file) first in
ASDF/EXTENSIONS then ASDF, for backwards-compatibility, then one day
only ASDF/EXTENSIONS.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20160215/b99aa09a/attachment.sig>