[asdf-devel] TEST-OP made useful by declarative options

[Robert Goldman]

On 4/17/10 Apr 17 -6:10 PM, Juan Jose Garcia-Ripoll wrote:
> A simple example that takes the RT package, which is a rather fragile
> testing framework, and wraps it inside an ASDF system using the previous
> ideas I just coded.
> 

....

> The plug-in in asdf-rt.lisp reveals various deficiencies:
> 
> - If we want a purely declarative syntax, without side effects, we have
> to specify symbols in other packages using strings (see the
> asdf-rt:rt-test-system) clas below.
> - The parsing of DEFSYSTEM currently can not be customized by the class.

With all due respect, this is at one and the same time not true, and the
way it should be(!)

Not true:  DEFSYSTEM is a macro which means that any ASDF extension can
call for arbitrary s-expressions to be passed as argument values, and
can then process these arguments to its own satisfaction.

It's a feature:

1.  I am surprised to hear you, of all people, call for allowing ASDF
extensions to customize the parsing of DEFSYSTEM, since this seems to
directly contradict your desire for ASDF to become more declarative.

2.  The current arrangement permits extended ASDF systems to be
processed by core ASDF.  For example, if a user doesn't have the test
framework (and I don't believe that we should ever force an ASDF library
user to install a particular test library), ASDF will simply ignore
initargs that are appropriate only to the test library, because of
DEFSYSTEM's permissive &allow-other-keys argument processing.

> - Adding components to a module is not done using SHARED-INITIALIZE and
> this is bad because, once more, additional classes can not extend or
> process the list of components.

This is an interesting point.  What obstacles would there be to revising
the defsystem processor to use SHARED-INITIALIZE in ASDF 2+?  Or, if
SHARED-INITIALIZE would be inappropriate, could we add an ASDF API
method that would do something similar, and which would allow for user
configuration of an initialization protocol.

Best,
r