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@googlemail.com> wrote:
On Mon, Apr 19, 2010 at 8:01 PM, Faré <fahree@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