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