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

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.

(2) Second, make FIND-SYSTEM be a wrapper around an ASDF operation, so
    that a protocol like (1) will be available during
    FIND-SYSTEM-time.  For example, (I'm a rusty on the ASDF protocol,
    so I might be forgetting things, but something like this):

    (defclass find-system-op (operation)
       ())

    ;; OPERATE calls FIND-SYSTEM when the second argument isn't a
    ;; component, so we need some indirection to avoid infinite 
    ;; recursion.
    (defun find-system (thing)
       (if (typep thing 'system)
           thing
           (operate 'find-system-op
                     (make-instance 'component :name thing))))

    (defmethod operation-done-p ((op find-system-op) thing)
       (system-registered-p thing))

    (defmethod perform ((op find-system-op) thing)
       #| the current body of FIND-SYSTEM can go here |#)

    This way, FIND-SYSTEM will be a call to OPERATE, so that a
    protocol along the lines of (1) will be available to inferior
    calls to OPERATE inside an .asd file.

I haven't tried implementing either of these things; the details might
be wrong, or they might not work at all.  I'll try this out this
afternoon or evening.

Anyhow, for SBCL's release timing purposes, we have a few weeks to
puzzle this out, so I don't need a hasty solution today if we can come
up with a better solution tomorrow.

--
Richard


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