On 2010-04-20, at 19:57 , Juan Jose Garcia-Ripoll wrote:
On Tue, Apr 20, 2010 at 6:17 PM, james anderson james.anderson@setf.de 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?
if the concepts are "difficult to fit in one or two words", then the expression form should disambiguate rather than obscure.
just as (defstruct (person (:print-function print-person)) name age sex) is better than (defstruct person :print-function print-person name age sex) or (with-open-file (stream "here" :direction :input) (read stream)) better than (with-open-file stream "here" :direction :input (read stream))
a pattern such as (defsystem (a-system :class extended-system :require some- implementation) :components ((:file x))) is better than (defsystem a-system :class extended-system :require some-implementation :components ((:file x)))
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.
if it might be possible to confirm that the shortlist, above, is a complete statement of the problem, that would help.
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
That would cause less pain because it could be macroexpanded, but it would fail to annotate the system form itself with a dependency,
is that one of the requirements? one of the earlier discussions suggested that the load protocol be implemented as a restricted read- eval loop. which would itself be in a position to collect any annotations.
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?
it depends on whether the requirement is that it behave like use/in- package or like :metaclass. given the present formulation, what is the consequence of a dependency which appears in more than one system definition. is it reloaded or not? what happens if the features have changed since it was first loaded? is the behavior by intent, or a side-effect of the implementation?
a second form would be to elaborate the system name by attaching the annotations to it.
Why the system name?
it is a conventional locations. (see above.)
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.
if you would like to pursue that path, we can discuss whether the meta-annotations actually apply to the operator, and, as such, it would be more appropriate to declare the system as
((defsystem :class extended-system :require some-implementation) a- system :components ((:file x)))
but that is outside of the present thread.
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.
as of last reading, they were loaded by default into a temporary package which was then deleted. is this the appropriate package? if so, why?
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.
why tokens? what function do they support and why are tokens the best way to accomplish that? why is it better to specify the future home package that it would be to search for it? why is that better than it would be to always use the same package? why is it better than to use a package named after the system?
3- we annotate the system definition with meta-dependencies.
what are meta-dependencies? - packages? - classes in packages? - systems? - features? - ?
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.
before perform? before operate-on-system? before shared-initialize starts? completes? before initialize-instance starts, completes?
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.