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/