[asdf-devel] :ASDF-DEPENDENCIES implemented

[Juan Jose Garcia-Ripoll]

On Sun, Apr 18, 2010 at 5:24 PM, Robert Goldman <rpgoldman at sift.info> wrote:

> On 4/18/10 Apr 18 -10:18 AM, Juan Jose Garcia-Ripoll wrote:
> > Ideally the situation could be such that the loading of dependencies
> > could be delayed until the system is actually used. In other words, load
> > the system definition using the base class, record components,
> > dependencies, etc, Only when the system is actually loaded, compute the
> > dependencies which are present and can be used and change the class
> > using the extensions which are really available.
>
> I was thinking one might do a two-phase process in which the
> :asdf-dependencies (and proposed :asdf-optional-dependencies) would be
> loaded first.  Then the remaining defsystem initargs would be processed.
>  Any reason not to do that?
>

This is actually how I implemented it, though the load step could be moved
into the macro expansion itself, but I think it would be nice to also load
system descriptions without having any further side effects, such as
compiling and loading all of CFFI. If we impose that the dependencies and
components have to be understood by ASDF we could create the dependency
graph _without_ the :ASDF-DEPENDENCIES being even present (Thinking right
now of an automated scan of *.asd files in some web based software
repository and things like that).


> > - Right now people are using symbols in other packages.
>
> This seems quite undesirable.  You can't even /read/ such symbols
> reliably.  Currently this works because the forms that load the asdf
> dependencies are lexically before the DEFSYSTEM form.  But putting the
> asdf-dependencies there would make this impossible.  We would need to
> find a solution much less cumbersome than the current
>
> (funcall (intern <function name> <extension package>) ...)
>
> or similar constructs which I find myself typing more often than I'd
> like in PERFORM methods...
>

Yes, this has to be sorted out. It is the real stopper towards purely
declarative systems. From a simple inspection, the problem with packages
seems right now constrained to
- component names
- :perform options in components (seems deactivated right now)
- perform methods that are system-specific (EQL specialized)
- some tuning of software variables / options / features

I have several ideas some of which amount to the following ingredients:
+ Reader macro magic
+ the expansion you mentioned
+ storing code as is
+ automated use of EVAL

The use of reader macros with some syntax ~absent-package::symbol could be
used to keep a "to be constructed" form of symbol in an S-expression for the
code that makes up the PERFORM methods and options (Alternatively we could
use just strings) This could would then be evaluated or coerced into a
lambda form only when needed -- and thanks to the dependency mechanism that
would be when the packages do already exist.

Note that this is one of the reasons why I think that ASDF gets it wrong
when writing rules which are specific to a system or to components that are
only present in that system: in that case CLOS is an overkill and forces you
to write methods _before_ we have installed any of the actual packages and
functions the method depends on. Fixing this hack of storing
system-dependent actions in the generic function PERFORM would be
interesting mid-term goal.

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/20100418/a69663b1/attachment.html>