[asdf-devel] :ASDF-DEPENDENCIES implemented

[james anderson]

good afternoon;

On 2010-04-20, at 15:26 , Faré wrote:

> I think defsystem-depends-on fits the current interface better indeed.
> If no one complains today, I'll commit that as 1.705.

please understand this note as a complaint.

>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http:// 
> fare.tunes.org ]
> May your desire to be correct overcome your desire to have been  
> correct
> (which you were not, anyway).
>
>
> On 20 April 2010 04:10, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
>> On Mon, Apr 19, 2010 at 8:01 PM, Faré <fahree at gmail.com> wrote:
>>>
>>> I pushed Juanjo's patch for :ASDF-DEPENDENCIES as 1.704, except  
>>> that I
>>> renamed the feature :SYSTEM-DEPENDENCIES. Maybe it should have been
>>> :SYSTEM-DEPENDS-ON. Ahem. You tell me what you think.
>>
>> There is obviously a naming problem.
>>
>> :system-dependencies looks like the dependencies are equivalent to
>> :depends-on
>> :asdf-dependencies is ugly and does not give much information
>>
>> I could suggest,
>>
>> :meta-dependencies which is ugly, but may ring a bell (AMOP)
>> :defsystem-depends-on which is more like a sentence (current spirit)

that there is such difficulty to select a stable term indicates that  
the form of the expression is wrong.
the mechanism[1] which hard-wires parameter segregation in the  
defsystem macro is a tell-tale.

the implementation note[2] did not offer any reasons for the change,  
but it is possible to infer some functional requirements from earlier  
messages[3,4]:
   it should be possible to interpret a system definition without  
performing arbitrary computation
     the interpretation includes constructing and/or interrogating  
the intra- and inter-system dependency graph
     it includes identifying designated files
   it should be possible to extend asdf operations on system, module,  
and file model components declaratively, in a manner such that the  
declaration still yield a valid definition in the absence of any  
extension
     this includes to specify additional initargs in the specification
     this includes to specify classes which are not defined in the  
asdf core.

the asdf defsystem protocol fails these requirements in several ways:
   the declaration syntax is a "single level" expression - (name .  
properties), which permits attributes with respect to the application  
source components - file, packages, external libraries only, while  
any extension specifications are intended with respect to the system  
definition itself, eg.
   - the system, module, and file component classes;
   - permissible arguments
  the instantiation protocol provides limited support for non-core  
class designators and requires that
   - all packages must exist before the declaration is read,
   - all classes must be defined before the declarations is interpreted.

note that all of these issues apply to the model itself, not to the  
modeled application. in which case, the pertinent declaration forms  
should be distinct from those which apply to the system components.

there are at least two ways to accomplish the syntactic machinations.  
one would be to follow the standard source patterns and standardize  
an independent expression - either in the same file or elsewhere. in  
the sense that the requirement is on the same order as a in/use- 
package, it should stand alone. a second  form would be to elaborate  
the system name by attaching the annotations to it. in this second  
case, one could also consider formailzinf the protocol in an  
operator, eg ensure-system, with an interface which captured the  
three aspects - identity, implementation, and constituency.

there are several ways to support the late-binding for the system/ 
module/implementation classes. the existing asdf implementation  
already delays the process somewhat in the way it resolved classes by  
permitting the use of keywords. one can conceive of a protocol which  
relied on the same search process as applies to systems to be applied  
to the classes themselves during system construction. this would,  
however. mean that the current suggested practice of interpreting  
system declarations in a null package would be replaced with one in  
which the package was significant.

some such thing would be much preferred to editing the declaration  
argument list and implementing the protocol as a progn. these are  
just initial thoughts as to how to approach the problem. they should  
be elaborated before one commits to a solution.


---
[1] : http://tinyurl.com/y7q3ca4
[2] : http://common-lisp.net/pipermail/asdf-devel/2010-April/001374.html
[3] : http://common-lisp.net/pipermail/asdf-devel/2010-March/001099.html
[4] : http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf