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