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