Re: Could there be a way to disable LOAD-PREFERENCES?

Richard M Kreuter wrote:
> "Robert P. Goldman" <[email protected]> writes:
> 
> (I think I forgot to reply to this, or maybe forgot to CC the list.)
> 
>> Richard M Kreuter wrote:
>>
>>> So I think there are two problems:
>>>
>>> * calling OPERATE to extend ASDF in a .asd file occurs during the
>>>   execution of FIND-SYSTEM, which the user can call separately from
>>>   OPERATE,
>>>
>>> * even when loading the .asd file is a result of a top-level call to
>>>   OPERATE, there's no protocol to communicate information between
>>>   outer and inner calls to OPERATE.
>>>
>>> I don't have a simple suggestion for how to deal with this right now,
>>> but I do have a complex, two-part solution whose consequences I
>>> haven't yet worked out (so if anybody sees a problem, please speak
>>> up!):
>>>
>>> (1) First, establish a protocol whereby inferior calls to OPERATE
>>>     receive outer calls' initargs.  Here's one such protocol: have
>>>     OPERATE bind some special variable, say, *SUPERIOR-OPERATION*, to
>>>     the operation instance it constructs.  Then, whenever
>>>     *SUPERIOR-OPERATION* is an operation, have OPERATE supply
>>>     *SUPERIOR-OPERATION*'s initargs as arguments to operations it
>>>     constructs after any other supplied args, so that inferior
>>>     invocations of OPERATE inherit superior invocations' initargs.  So
>>>     passing down a :LOAD-PREFERENCES initarg will "just" occur, so to
>>>     speak.
>> Isn't there already a partial solution like this in place?  
>>
>> That is, when you create subsidiary *operations* they get initargs
>> from the parent operations (see make-sub-operation).
> 
> The problem I'm talking about above is that some .asd files contain
> things like this
> 
>   (eval-when (:compile-toplevel :load-toplevel :execute)
>     (asdf:operate 'asdf:load-op "some-asdf-extension"))
> 
> In these cases, the system being loaded by an inferior call to OPERATE
> will receive only the initargs in the file.  These OPERATE calls are
> not part of the planning done by TRAVERSE, but side effects of LOADing
> .asd files.

And this is necessary because one needs to have loaded the system in 
question (in your example "some-asdf-extension") in order to be able to 
even load the asd DEFINITION, not just to load the asdf system in question.

Hm...  It's not even entirely clear to me what is the right thing in 
this context.  If the other system is loaded in order to load the asdf 
*definition*, rather than the asdf system itself, it seems entirely 
appropriate to me that it would NOT inherit the initargs.  After all, if 
one is going to :force recompilation of one's own system, that's not a 
good reason to force recompilation of the ASDF infrastructure, as in 
your example....

I'm having a hard time seeing why this is a problem, since it seems like 
either (a) the user would be configuring this system 
(some-asdf-extension) him/herself, and would be quite capable of 
ensuring it's loaded properly or (b) the user wouldn't know about 
some-asdf-extension, so the user wouldn't have any local preferences 
anyway....

But this is the product of all of 90 seconds of thought, so I may well 
be missing something here.

Best,
Robert

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/