On Tue, Apr 20, 2010 at 6:17 PM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
that there is such difficulty to select a stable term indicates that<br>
the form of the expression is wrong.<br></blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
the mechanism[1] which hard-wires parameter segregation in the<br>
defsystem macro is a tell-tale.<br></blockquote><div><br>I do not like the current mechanism and I have made it explicit.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
the implementation note[2] did not offer any reasons for the change,<br></blockquote><div><br>This was a followup on various messages, as you have been able to find. <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
the asdf defsystem protocol fails these requirements in several ways:[...]<br>
the instantiation protocol provides limited support for non-core<br>
class designators and requires that<br>
- all packages must exist before the declaration is read,<br>
- all classes must be defined before the declarations is interpreted.<br></blockquote><div><br>Indeed this is a problem.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
note that all of these issues apply to the model itself, not to the<br>
modeled application. in which case, the pertinent declaration forms<br>
should be distinct from those which apply to the system components.<br></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
there are at least two ways to accomplish the syntactic machinations.<br>
one would be to follow the standard source patterns and standardize<br>
an independent expression</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> a second form would be to elaborate<br>
the system name by attaching the annotations to it.</blockquote><div><br>Why the system name?<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
there are several ways to support the late-binding for the system/<br>
module/implementation classes. the existing asdf implementation<br>
already delays the process somewhat in the way it resolved classes by<br>
permitting the use of keywords. one can conceive of a protocol which<br>
relied on the same search process as applies to systems to be applied<br>
to the classes themselves during system construction. this would,<br>
however. mean that the current suggested practice of interpreting<br>
system declarations in a null package would be replaced with one in<br>
which the package was significant.<br clear="all"></blockquote><div><br>I do not agree. My view right now is the following:<br><br>1- system definitions continue to be read in the appropriate package.<br>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.<br>
3- we annotate the system definition with meta-dependencies.<br>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.<br>
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).<br>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.<br>
<br>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<br><br>Juanjo <br></div>
</div><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>