Re: side effects and a complr bug.

[George J. Carrette <GJC at MIT-MC>]

There is a possible incompatiblity between lisp machine lisp
and maclisp and NIL with respect to the handling of side effects.
Here is a wallpaper file with an example:


((DSK GJC) LWALL /1) 

(defun mapcc (f v)
       (do ((l v))
           ((null l) v)
           (setf (car l) (funcall f (pop l)))))
MAPCC 

(setq a '(1 2 3 4 5) b '(1 2 3 4 5) f '(lambda (u) (list 'f u)))
(LAMBDA (U) (LIST (QUOTE F) U)) 
; test1
(mapcc f a)
((F 1) (F 2) (F 3) (F 4) (F 5)) 
; neat
(chomp mapcc)
(MAPCC) 
; test2
(mapcc f b)
;((F (F (F (F (F 1)))))) NIL CLOBBERED

;BKPT FAIL-ACT
QUITQUIT
b 
(1 (F 1) (F (F 1)) (F (F (F 1))) (F (F (F (F 1))))) 
; ah, so thats what its doing!
(walend)

The maclisp expanders for SETF/PUSH/POP try very hard to guarantee
the order of evaluatation as the lexicaly apparent order of evaluation,
and to also keep the number of evaluations to 1.
The macros themselves also try to avoid creating extra temporary
locations, which is hard to do sometimes without error,
I guess thats what causes the bug once MAPCC above is compiled.

The DEFUN-KEYED macro of BAK is another example. The order of
evaluation of the arguments is given by the macro definiton,
not by the apparent calling of the function. Its easy enough
to make sure the evaluation is as apparent in the call, although
arguments for not doing this can be made in terms of efficiency
of the run-time or the compiler.

Question: What do you think we should do about all this?

-gjc

p.s. I just HAD to come up with something to get people off of
DIGIT-WEIGHT!