On Sun, Apr 18, 2010 at 5:24 PM, Robert Goldman <rpgoldman@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