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

"Robert P. Goldman" <[email protected]> Tue, 26 Feb 2008 11:15:58 -0600
Newsgroups gmane.lisp.cclan.general
Organization SIFT, LLC
Message-ID <[email protected]>
Richard M Kreuter wrote:
> Gary King <[email protected]> writes:
> 
>> Here is my diff for the suggested change. If there are no squawks,  
>> I'll commit tomorrow sometime.
> 
> One squawk, unfortunately.  While the keyword argument to OPERATE
> mostly does the right thing, it does have a drawback: the normal way
> to use a system that extends ASDF is to have a separate call to
> OPERATE to load the ASDF-extending system.  SBCL uses this
> functionality: sb-posix loads sb-grovel this way at the top of the
> .asd file:
> 
> (cl:eval-when (:compile-toplevel :load-toplevel :execute)
>   (asdf:oos 'asdf:load-op :sb-grovel))
> 
> 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).

make-sub-operation really needs to turn into a generic function....

Cheers,
R


-------------------------------------------------------------------------
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/