[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SETF's return value
- To: RWK at MIT-MC
- Subject: SETF's return value
- From: Jon L White <JONL at MIT-MC>
- Date: Sat, 22 Aug 81 06:21:00 GMT
- Cc: BUG-LISP at MIT-MC, NIL at MIT-MC
- Original-date: 22 August 1981 02:21-EDT
I notice that the LISPM still holds that the value of SETF
is undefined; the MacLISP/NIL SETF is trying very hard to
return the "value" which is put in the the accessed frob,
apparently so that SETF will parallel SETQ in some sense.
In some cases, SETF doesn't have to try too hard, since
the corresponding updator function returns that value, but
in others, the updator function returns the frob just
updated. E.g., STORE (and ASET) returns the value just placed
into the array, but RPLACA returns the cons cell.
The NIL documentation has never specified what the
return values of the updators for various sequences should
be, but we've been assuming all along that they would be
parallel to RPLACA -- namely return the sequence instead
of the component value. Is there any consensus in
leaving these undefined, as with the LISPM SETF?
Is there anyone who has a reason to depend upon the
value of the new updator functions?