Question about DEFSYSTEM-DEPENDS-ON

[Robert Goldman]

Per my recent post to launchpad, I don't think dependency updating is
the fatal flaw in D-D-O.  D-D-O's bad interaction with the package
system is worse.

Specifically, D-D-O cannot be used to introduce ASDF extensions unless
those ASDF extensions live in the ASDF package.  Otherwise, by the time
a DEFSYSTEM form is read, the enclosing package's imports are already
established.  This means that ASDF has no protection against namespace
pollution, since extenders are practically forced to add symbols to ASDF.

For example, we have a FIVEAM-ASDF extension that introduces a new
defsystem class that has features for using 5AM as an implementation for
the TEST-OP.  But we cannot put a DEFSYSTEM-DEPENDS-ON for FIVEAM-ASDF
in a system and reference FIVEAM-ASDF:FIVEAM-TESTER-SYSTEM as the system
class, because the FIVEAM-ASDF package does not (in general) exist when
the enclosing DEFSYSTEM is read.

I can think of three ways of handling this:

1. Deprecate and remove D-D-O.  This seems undesirable, since D-D-O is
commonly used.

2. Replace the use of the lisp reader for processing DEFSYSTEM forms,
and introduce some kind of parser.  This seems like an enormous amount
of work and difficult to get right.

3. In some way extend the keyword-processing features of DEFSYSTEM to
allow it to reference symbols that are not only in the current package
and ASDF, but also programmer-specified packages.  Unfortunately,
processing of keyword symbols in DEFSYSTEM is very case-specific -- we
know particular locations where there use is permitted, and handle each
one specifically.  Without a cleaner way to handle this, we are likely
to simply be backing ourselves into alternative #2.  OTOH, if we *could*
do this, it would be a great solution, because it would maintain the
maximal amount of backwards-compatibility.

This is the problem I would most like to see solved in ASDF.