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.
it would be nice to have concrete use cases. lacking them, these lists of goals require that there be some mechanism independent of asdf to effect the logical host definitions. which does not convince of a need to add the mechanism to asdf itself.