janson@athena.mit.edu (James A Anderson) (11/27/90)
does anyone know why the arguments are reversed in the function which is generated by a defmethod for a setf function? for example (from Lucid 4.0) : > (defclass thing nil ((attribute :allocation :instance :accessor thing-attribute))) #<Standard-Class THING> > (macroexpand-1 '(setf (thing-attribute some-thing) to-this)) (LET* ((#:G1754 SOME-THING) (#:G1753 TO-THIS)) (SETF::2.OG.THING-ATTRIBUTE #:G1753#:G1754)) T > (describe #'SETF::2.OG.THING-ATTRIBUTE) #<Standard-Generic-Function (SETF THING-ATTRIBUTE) (1)> is an instance of the class STANDARD-GENERIC-FUNCTION: The following slots have allocation :INSTANCE: NAME (SETF THING-ATTRIBUTE) LAMBDA-LIST (CLOS::NEW-VALUE THING) DOCUMENTATION NIL METHODS (#<Standard-Writer-Method (SETF THING-ATTRIBUTE) (T THING)>) METHOD-CLASS #<Standard-Class STANDARD-METHOD> ARGUMENT-PRECEDENCE-ORDER :DEFAULT METHOD-COMBINATION STANDARD DECLARATIONS NIL > which shows, in the "standard-write-method" the reversed args. the same arrangement reqults if the method is defined with an explicit defmethod. the original pcl/defs.l definition of do-standard-defsetf-1 describes: ;;; Call this to define a setf macro for a function with the same behavior as ;;; specified by the SETF function cleanup proposal. Specifically, this will ;;; cause: (SETF (FOO a b) x) to expand to (|SETF FOO| x a b). i would expect (from CLTL) that the the value argument be appended onto the arguments used by the reader function. this (confusing) behaviour has been retained at least as far as the (beta) CLOS which is present in Lucid 4.0 . can someone explain why this convention was adopted and whether it will persist? thanks. j anderson.
barmar@think.com (Barry Margolin) (11/27/90)
In article <1990Nov27.023907.10083@athena.mit.edu> janson@athena.mit.edu (James A Anderson) writes: >does anyone know why the arguments are reversed in the function >which is generated by a defmethod for a setf function? This is so that the <place> argument to SETF may include keyword, optional, and rest parameters. If the <value> argument were last it wouldn't be possible to precede it with optional or keyword arguments. The method might need to specialize on the type of the value argument, but only positional arguments may be specialized. And no arguments can follow keyword arguments. So, it's not really the case that the arguments are *reversed*. The arguments are in the same order, except that the value argument is moved to the front. For a simple example, consider the function that SETF of AREF must expand into a call of (in Zetalisp it's called ASET). It should take the subscripts as an &rest argument just as AREF does. So where does the value argument go. In Zetalisp, the argument list is (new-value array &rest subscripts). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar