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

[Eric Timmons]

On Tue, Feb 16, 2016 at 3:14 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> On 2/16/16 Feb 16 -10:12 AM, Eric Timmons wrote:
>> On Mon, Feb 15, 2016 at 3:34 PM, Robert Goldman <rpgoldman at sift.net> wrote:
>>>
>>> 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.
>>
>> Would there be anything wrong with saying everyone should use strings to name
>> symbols from ASDF extensions? Component types and :class already seem to support
>> this. A quick glance through the code makes me think :in-order-to and inline
>> methods would be fairly easy to modify to support it as well. I'd be happy to
>> send in a patch for it.
>>
>> It seems this would solve the issue with namespace clashes and get rid of the
>> need for load-systems before the defsystem. There's still a lot of work if
>> someone wants a completely declarative version of defsystem, but at least it's
>> a step in that direction.
>
> I don't see that strings make an obvious improvement over the way we use
> keywords.  Here's the situation:
>
> Keywords are interpreted as follows:
>   i. names in current package (this is how we get in extensions, if we
> have imported the extension package into the current package)
>   ii. names in ASDF (this is how we get in extensions if we have done
> the Bad Thing and imported our extension names there).

Sorry, I think I may not have expressed what I meant clearly. When I
said strings,
I really meant "strings containing a fully qualified symbol name". To
use CFFI as
an example, this:

```
 (cl:eval-when (:load-toplevel :execute)
    (asdf:operate 'asdf:load-op 'cffi-grovel))

  (asdf:defsystem example-software
    :depends-on (cffi)
    :serial t
    :components
    ((:file "package")
     (cffi-grovel:grovel-file "example-grovelling")
     (:file "example")))
```

Would become this:

```
  (asdf:defsystem example-software
    :depends-on (cffi)
    :defsystem-depends-on (cffi-grovel)
    :serial t
    :components
    ((:file "package")
     ("cffi-grovel:grovel-file" "example-grovelling")
     (:file "example")))
```

This is already supported for component types and the :class argument (using
coerce-class). I can't find it in the documentation (but I could swear
I saw it in
there at some point).

The logic in coerce-class does exactly what you're describing for symbols and
keywords. For strings it uses uiop:safe-read-from-string. Since the reader never
sees the symbol from the extension package before it's loaded, there's no need
to load-system it beforehand. But if someone doesn't want to always prefix with
a package name, they can continue loading the system beforehand and using the
symbol.

It looks like minor tweaks to the code to add the same support to operations in
the defsystem as well. It's the same logic as coerce-class, just possibly
without a find-class in there.

Strings do have a certain ugliness to them that keywords don't, so
maybe this isn't
the best direction for ASDF. But I think making support for this
uniform, locking the
ASDF package, and encouraging people to use it would solve the namespacing
problem.

-Eric