On Tue, Apr 20, 2010 at 6:17 PM, james anderson <[email protected]>wrote:
> that there is such difficulty to select a stable term indicates that > the form of the expression is wrong. > Not really. It simply shows that some concepts are difficult to fit in one or two words -- as in :weakly-depends-on How weakly? Condition? Requirement? Works without, builds without? > the mechanism[1] which hard-wires parameter segregation in the > defsystem macro is a tell-tale. > I do not like the current mechanism and I have made it explicit. > the implementation note[2] did not offer any reasons for the change, > This was a followup on various messages, as you have been able to find. the asdf defsystem protocol fails these requirements in several ways:[...] > 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. > Indeed this is a problem. > 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. > Sorry, this paragraph is plain to abstract for me to understand. Indeed I find the discussion in general too abstract. It would be nice if you could formulate it in plain words that a reader of a "Users guide" can understand. > 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 That would cause less pain because it could be macroexpanded, but it would fail to annotate the system form itself with a dependency, which I, against your way of thinking, is there -- just like a STANDARD-CLASS depends on the existence of such class to process its arguments, this is a meta-dependency: we need a system to parse the existing system. Would you then have the :metaclass argument outside DEFCLASS? > a second form would be to elaborate > the system name by attaching the annotations to it. Why the system name? I insist. CLOS classes do have meta-annotations that give information on how to process the class definition itself, XML does as well, at least from a writer's point of view -- I do not know the programmer's side, which you know better having implemented a library for XML yourself. 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. > I do not agree. My view right now is the following: 1- system definitions continue to be read in the appropriate package. 2- at some point we may introduce tokens with late bindings to packages -- this is essential for rules that depend on functions that depend on packages that are not created. 3- we annotate the system definition with meta-dependencies. 4- We make _no_promise_, absolutely no promise about when the meta-dependencies will be use. In this sense this is exactly like the MOP class finalization protocol. 5- At some point we will decide to actually use the system for something else than querying dependencies or inspecting the semantic annotations (author, description, components, etc). 6- It is in that moment that meta dependencies will _typically_ be ensured, the system and components will be finalized to the appropriate classes and we will have fully working dependencies. This is *not* what was implemented right now. What is implemented at the moment implicitly loads the dependencies before the system definition is parsed. However that still fits within the rule 4 Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
_______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
