[asdf-devel] :ASDF-DEPENDENCIES implemented

[Juan Jose Garcia-Ripoll]

On Tue, Apr 20, 2010 at 6:17 PM, james anderson <james.anderson at 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?


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100420/d24b9738/attachment.html>