Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!bloom-beacon!athena.mit.edu!janson
From: janson@athena.mit.edu (James A Anderson)
Newsgroups: comp.lang.clos
Subject: defmethod setf expansion
Message-ID: <1990Nov27.023907.10083@athena.mit.edu>
Date: 27 Nov 90 02:39:07 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: janson@athena.mit.edu (James A Anderson)
Organization: Massachusetts Institute of Technology
Lines: 47

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.