[asdf-devel] SBCL port of ECL's extensions

[Robert Goldman]

On 3/29/10 Mar 29 -11:05 AM, Juan Jose Garcia-Ripoll wrote:
> On Mon, Mar 29, 2010 at 5:47 PM, Robert Goldman <rpgoldman at sift.info
> <mailto:rpgoldman at sift.info>> wrote:
> 
>     I.e., can you characterize this declaratively in terms of the values of
>     MODULE-COMPONENTS, and for some operation the values of INPUT-FILES
>     and/or OUTPUT-FILES?
> 
> 
> I do not understand your concerns or those in other messages. I do not
> intend to change the API, nor the way TRAVERSE works.  I just want to
> code a _separate_ function that ensures we gather everything that is
> needed for a system to load. I see three uses of a better coded
> GATHER-COMPONENTS
> 
> 1) Find the compiled files that make up a system
> 2) Find all the components that make up a system
> 3) Find all the files that make up a system
> 
> In case 1) which is the one I am most interested in the behavior should
> be as follows. Assume lisp L is a fresh new image with only ASDF in it
> and assume system S is the system we want to gather information about.
> Assume that L is used ONCE with S using operation LOAD-OP. Exit that
> lisp image and load L AGAIN and apply LOAD-OP on the same system S.
> GATHER-COMPONENTS  should return the list of files that are LOADed in
> the second phase, for this is by definition the set of files that
> actually make up a system.

Thanks, that helps.  But it isn't really what I'm asking, which is "how
would you characterize this in terms of existing ASDF functions (I think
MODULE-COMPONENTS, INPUT-FILES, OUTPUT-FILES and, given what you've
said, IN-ORDER-TO).  I'm not trying to be pedantic, but we are allowing
people to extend the ASDF object model by creating their own components
and operations.  So we need to understand what implications this new
GATHER-COMPONENTS is to have on extensions.

Note that your definition of GATHER-COMPONENTS is made in terms of
operations that are done outside the lisp itself.  So I don't think it
is well-defined in terms of ASDF operations (asdf is not set up to
support, for example, "pretending" that it hasn't loaded a system).
Without such a clear definition, that doesn't appeal to outside
operations like "start a fresh lisp," we do not have a clear
specification for implementing GATHER-COMPONENTS.

Note that this would /not/ be true if we were to implement
GATHER-COMPONENTS by actually starting up a separate, clean lisp
process, and harvesting information out of that lisp process.  If we
were to do that, then your definition would be sufficient as a
specification.


> 
> Case 2) could be coded as case 1) but instead of gathering the files at
> the end, gather the list of all components.
> 
> Case 3) requires new syntax because right now we do not have ways to
> list all the resources that belong to a system, do we?

it's not even clear what is meant by "all the resources that belong to a
system."  Let's return to my protocol example.  Consider, for the sake
of example, that I have ".proto" files that are translated, using a perl
script, into ".lisp" files (call this 'proto-to-lisp-op).  Now I have a
system that contains a component like this:

(:proto-file "IRC-proto")

and we specify that we must perform a proto-to-lisp-op to generate
IRC-proto.lisp from IRC-proto.proto before we can do the COMPILE-OP.

What's the resource here?  Is it the .proto file?  the .lisp file?
Which should be returned for your use case #3?

This is what I mean by "extending the API," although "API" might be
wrong there.  Maybe "protocol" is meant.  People generating .asd files
have had no reason to think about this question of "resource" that you
are raising here, so it's quite likely that adding this new facility
will not work on previously-existing systems.

That is the reason that I'm arguing for pushing this out into ASDF 3.

Note also that this will be much easier to do if a more declarative ASDF
(where dependencies needed for system definition loading are made
declarative, instead of requiring calls to asdf:oos in .asd files,
etc.), so that would be another reason to push this into ASDF 3.

best,
r