&AUX list backwards in MacLISP

[Jon L White <JONL at MIT-MC>]

    Date: 16 October 1981 00:09-EDT
    From: William G. Dubuque <WGD at MIT-MC>
    (defun car&cdr (list &aux (car (car list)) (list (cdr list))) 
	   (values car list))
    (car&cdr '(a b)) ==> (values 'b '(b))
    It appears that defun& is totally losing here, switching the order 
    of the &aux's and performing a boundp check on list. This works on 
    the Lispm and in NIL.
Both Lispm and a real NIL have "native" modes for binding the &optional
and &aux variables, so only MacLISP has to try to "patch it" into a
LET or LET* and kludge around.  But indeed, the MacLISP only version of
DEFUN& was returning a reversed list, and this is now fixed in DEFMAC 166.
    Date: 16 October 1981 00:58-EDT
    From: Kent M. Pitman <KMP at MIT-MC>
    .  .  .  I thought it was agreed that &AUX had
    the semantics of a LET* -- why doesn't it just turn into one and be done
    with it.  .  .  .  Am I confused or is someone just trying to save a 
    few cons's at the expense of correct code?
Some time back, there was a flurry of mail talking about the semantics of
binding for these & frobs -- originally the LISPM did a bind of all variables
to their former values, and then a sequential assignment; subsequently it
was changed to do incremental binding.  For a variety of reasons, the
incremental binding is a loss for MacLISP (more details if you are *really*
interested), so the MacLISP-only version of DEFUN& tries to emulate the
original Lispm behaviour.  This "incompatibility" is rather a moot point,
since the differences in semantics can only be detected when there is
SETQ'ing of free variables in the &aux or &optional computations;  the
reversal of the &aux list, was, however a real bug and has been fixed.
    Date: 16 October 1981 15:06-EDT
    From: George J. Carrette <GJC at MIT-MC>
    If you load "VAXMAX;DEFUN&" you will win. . .   However, we don't
    claim to support the stuff for any strange maclisp-only purposes you may
    have, but of course, if the price is right, maybe.
The NILCOM file DEFMAC had two completely different versions of DEFUN& --
one for use under NIL, and one for use under MacLISP having the properties
mentioned in the reply to KMP above.  That you chose to rewrite as much of 
this software as you could, in your own way, is a mark of your personality,
but it hardly helps the person like BIL who wants to write code that
will run both in MacLISP and NIL.   As mentioned above, I've fixed the 
MacLISP-only bug.   [yes, I know, you had to "do it right" -- don't you 
always? -- but you've introduced yet a third set of alternatives with minor 
semantic differences which *** are not moot points *** as the one difference 
with Lispm noted above.]