[asdf-devel] Enforcing pure *.asd files

[Juan Jose Garcia-Ripoll]

This is an idea that has been long floating in the back of my mind, and was
brought back to life by these comments
   http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf

The problem is that many people use *.asd files to do things like building
up packages, creating operations, defining methods, etc. That makes it
impossible to ship those libraries because the side effects are not recorded
in the system itself. So if ECL traverses the system to build a standalone
program it will know which sources are required, but those sources may for
instance rely on a package that was created in the *.asd definition.

My suggestion is a gradual move towards enforcing that *.asd files become
mere descriptions of the system and that side effects needed for building
and loading are listed in the system itself.

- System definitions should be read and recorded by ASDF in pure form, that
is as S expressions, with a hash that maps system names to s-expressions.
- Instead of using LOAD we use a LOOP and READ. If a form which is not a
DEFSYSTEM is found, we have two options: if we enforce strict mode, an error
is signaled, otherwise the form is evaluated after emitting a warning.
- Warnings could also be emitted when a DEFSYSTEM clause does not match the
name of the file, or when more than one such clauses is found.
- The system definition should be scanned for a class name and for a keyword
option, :asdf-support If the :asdf-support option is found, it should name a
file with side effects that are needed for the ASDF definition to be used.
The file should be loaded using LOAD.
- The original S expression is now parsed and the system definition is
created.

The warning could be really self-explanatory, stating the following:
- Dependencies that are needed for processing the system definition must be
listed in :asdf-support
- Dependencies that are needed for load/compile-op should be listed in
:depends-on

I can think on even more elegant ways to do this. For instance having proxy
classes, such as proxy-system and proxy-component which are used to store
the S-expression for the system and using change-class on these objects to
transform them into valid systems and components on demand, that is only
when the systems are needed.

It should also be possible to write an utility that grovels existing ASDF
systems looking for potential problems and suggesting changes.

What the solution above does not address is the following sentence from
Daniel's comment:

As to the "no".  Simply doing asdf:find-component may result in side
effects, both in the package of interest and in random other packages before
it.  These side effects include dumping fasls.  There are several asd files
that force things to load early in order to extend ASDF by defining custom
classes."

In other words, the side effects in :asdf-support can be really harmful, or
costly. However this proposal could help us identify what libraries do have
side effects and also help enforce further restrictions in the side effects
they may have.

I mean, there are many many other ways to do this, but I think you get the
idea.

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/20100318/5ac3a76f/attachment.html>