I believe what Juanjo wants here is an ability to have the LOADING of
the ASDF file generate some logical pathnames. So that after I
asdf-load my system FOO, then code /inside/ foo could use a logical
pathname like

"FOO:SRC;DATAFILES;DATA1.DAT"

with the guarantee that ASDF has set up the logical pathname
translations for "FOO:SRC;"

this may be true. it is part of what he has said. another part is, that the systems should work the same if built without asdf. there were two passages:

On 2010-03-30, at 12:00 , Juan Jose Garcia-Ripoll wrote:

Some considerations:

* In order to achieve a declarative syntax in ASDF, the system that we built it with should have the least knowledge about ASDF. In other words, it should work just the same if we bulid it with any other system.

On 2010-03-30, at 16:17 , Juan Jose Garcia-Ripoll wrote:

On Tue, Mar 30, 2010 at 4:06 PM, Robert Goldman <rpgoldman@sift.info> wrote:
FWIW, Faré provided a couple of new API functions to give ASDF users
this function, notably

SYSTEM-RELATIVE-PATHNAME

and

SYSTEM-SOURCE-DIRECTORY

I insist on the following: in order to achieve purity in ASDF files we want to keep as far away as possible from using any kind of API in the compiled code.

The best system build system is one which is invisible to the code that it builds.

Exposing functions, imposing the dependency of the user code on ASDF API as well as imposing that the library code queries ASDF for its own system is a very bad design.

We want system definitions to be descriptive, not programatic, and we want the user code to be able to exist in an ASDF-free environment, as standalone systems. The existing situation does not allow this.