Fix defsystem to accept strings as operation designators

[Faré]

In a bug reminiscent of the situation with component classes before ASDF 2.016, it is not possible to designate operation classes before their package exists, making defsystem-depends-on ineffective as a way to declaratively enable new operation classes. This matters more now that ASDF 3 makes defining new operation classes more useful, by allowing operations to better control their propagation.

My build-op branch on the git repository, currently at commit 5430fe44f095d1cd159a4a4d91d54ec31cad7878 implements these changes.

This branch also renames the completely unused build-system simply to build, in a bid to make it more usable. This is a separable issue, if the rename is disputed. The alternate name make was suggested. (As for a shorthand to load-system, aload was suggested, but that's again a different issue.)

[Robert P. Goldman (rpgoldman)]

Question: can we use strings that name *package-qualified* operations and component classes?

If we do this, we get out of the current trap, which essentially forces the authors of ASDF extensions to push their extensions into the ASDF package, opening the door to name collisions.

If one could write something like this, the problem might be eased...

:in-order-to ((doc-op "DECLT-ASDF:DECLT-OP"))

[Faré (fahree)]

See the long discussion threads on asdf-devel:

http://thread.gmane.org/gmane.lisp.asdf.devel/3913
http://thread.gmane.org/gmane.lisp.asdf.devel/3920
http://thread.gmane.org/gmane.lisp.asdf.devel/3976

[Robert P. Goldman (rpgoldman)]

Those discussion threads are all about using BUILD-OP. I just looked, and none of them discuss using strings instead of symbols as operation names.

These all discuss the need/not need of BUILD-OP.

The big question, then, remains: do we get "::" in our string-based operation names? If so, I think this could be really useful. If not, I'm not sure what we win.

So we would resolve these names *after* loading the defsystem-depends-on right?

Thanks!

[Faré (fahree)]

Yes, I don't think there was any controversy about the ability to designate operation classes with keywords and strings. It complements the ability to do as well for component classes, which we already had to make defsystem-depends-on useful.

Before ASDF3, we didn't support new user-visible operations very well if at all. Now that such operations become more useful and potentially important, it's a good idea to support them better.

So yes, with this branch, you can name operations with "foo::foo-op" as well as :foo (if to be defined in package asdf or in *package*). This is symmetrical with same support for component classes (and actually is factored through the same function). And yes, such names are parsed at the last minute, therefore, after the defsystem-depends-on dependencies had a chance to be loaded — that's the whole point.

I don't think anyone opposed the existence of build-op, or a better name for build-system. The big question was about whether or not it should be advertised as the new "main interface" to ASDF. I believe we all agree now that this is a premature move.

[Robert P. Goldman (rpgoldman)]

Faré wrote:
> So yes, with this branch, you can name operations with "foo::foo-op" as
> well as :foo (if to be defined in package asdf or in *package*). This is
> symmetrical with same support for component classes (and actually is
> factored through the same function). And yes, such names are parsed at
> the last minute, therefore, after the defsystem-depends-on dependencies
> had a chance to be loaded — that's the whole point.

Quick follow-up: do we have a test case for this? If not, I could write
one.

It would be nice to know that we can forward reference symbols in
as-yet-undefined ASDF extensions.

I particularly like it that this would mean that programmers don't have
to jam all their extensions into ASDF/INTERFACE, potentially causing
collisions.

Best,
r

[Faré (fahree)]

Yes, my branch includes a new file test/test-defsystem-depends-on.script

Also, I had to preserve keyword:foo -> *package*:foo, because at least ironclad depends on it, but I think it should be deprecated.

[Faré (fahree)]

Committed in 3.1.0.104.

NB: build-system was renamed to make.