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/15/16 Feb 15 -2:19 PM, Stelian Ionescu wrote:
> 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.

I'm sorry -- I *do* see this as a problem.  And it's precisely the
problem that CL packages were intended to solve.  I do not agree that
this is a problem of the design of the CL reader that must be solved
socially.

I am willing to see a different solution than my proposal, but I will
not accept any solution -- including the status quo -- that requires
people to worry about every other possible ASDF extension.

If you want the maintainership, you can have it your way.  Otherwise,
this goes.

[..snip...]

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

Sorry, I'm not trying to be difficult, but that solution is unacceptable
to me.  From my POV as maintainer, it seems like the worst of all
worlds.  We would be introducing yet more moving parts -- a new package,
ASDF-EXTENSIONS, that we would have to keep track of -- without  solving
the problem of name collisions.  This seems strictly worse than the
status quo.

If someone wants to *fix* the double-parsing solution, that's fine.  But
I'm not going to keep around the broken double-parsing solution.

I'm willing to try to support what QL needs, but I need some help in return.