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