Re: method-lambda and apply-method-lambda

[kempf@Sun.COM]

    >    APPLY-METHOD method next-method-info &REST arguments

    I don't think this generic function is really necessary, 
    since APPLY, being itself
    implementation dependent, could be modified to do the right thing given
    a method function. 

  Jim, I think you must have missed the point.  The problem isn't that what
  APPLY does is implementation-dependent, but that the arguments to be passed
  to APPLY are implementation-dependent.  The most obvious case is the
  next-method-info info; there is no way for APPLY to deduce this from the
  other arguments, is there?  If there is a way, I might change my mind on
  suggesting a separate APPLY-METHOD primitive, but if there isn't a way,
  we have to have that primitive so that the caller can supply the information.

Why does the next method info have to be passed as arguments to APPLY or
an APPLY-like function in the first place? I thought the whole purpose of 
MAKE-METHOD-FUNCTION was to return a function for which that information
has already been installed in the (some) environment, or maybe I'm missing
something. And that NEXT-METHOD-INFO gets it. 

		       Some implementations of APPLY 
    already must differentiate based on whether the function object is a closure
    or not, since in the former case, the lexical environment must be
    modified to reflect the lexical environment of the closure, so the
    additional case of a method function is probably nothing new.
    However, it might be useful for metaobject programmers who want a hook
    for a metaclass specific way of applying a method. In that case, I think
    the NEXT-METHOD-INFO argument could be dropped, since the concept of
    a next method is specific to STANDARD-METHOD. 

  I disagree.  I think CALL-NEXT-METHOD should be available to all classes
  of methods that want it; I don't think it should be something magic for
  standard-method.

No, I didn't mean to imply that CALL-NEXT-METHOD would be magic. Look, 
here's my vanillia implementation for MAKE-METHOD-FUNCTION for STANDARD-METHOD:

(defmethod make-method-function 
  ((proto-method standard-method)
   (generic-function standard-generic-function)
   specializers
   qualifiers
   lambda-exp
   &optional macroexpand-env
  )

  `(flet 
	( (call-next-method (&rest args)
	    (if (check-args args ',specializers)
	      (apply (get-next-method-function ',proto-method) args)
	      (apply #'no-applicable-method ',generic-function args)
	    )
  	  )
        )
        ,lambda-exp
    )
)

The only "magic" here is GET-NEXT-METHOD-FUNCTION, and I can't think
of any other way to keep track of the next method function unless
the method knows about it's next method itself 
(though there may be some ways to speed
up getting it, but this is a specification). Is there something
I'm missing here?

						  The method metaclass method
    for this generic function would then implement any special processing
    for changing control flow.

  I don't think I understand this last sentence; do you have a specific proposal?

(defmethod apply-method ((method standard-method) &rest arguments)

  (apply (method-function method) arguments)
)

Other metaclasses might want to control method application via their
method metaclass object, but the default would be not to.

I think I've got a different (and perhaps wrong?) model about what's
going on. My model is that MAKE-METHOD-FUNCTION constructs a function
in which the metaclass dependent specialized control flow primitives
(e.g. CALL-NEXT-METHOD) are part of the lexical environment
seen by the user code (LAMBDA-EXP). Any other system dependent 
information needed to influence control flow (e.g. permutation tables)
would also need to be included, but naming access controlled so only system
code sees it. NEXT-METHOD-INFO, or whatever the accessor function
is named, is able to get at that information in some implementation
dependent way. Thus, the method function should be invokable via 
APPLY, with APPLY-METHOD more of a utility should a metaobject user
happen to have a method and not want to retieve the function.
want to use it. No hidden arguments to APPLY needed.

Anyway, let me know if this is making sense, or if it's only a result
of allergic reaction to springtime pollen.


		jak