AAIIEEE!!!!!! shit for brains!

[Alan Bawden <ALAN at MIT-MC>]

;;; In a fresh lisp (version 1997)

(setq x 222222)
222222 
(ldb 0603 x)
;Loading LODBYT 24 
;Loading DEFMAX 44 
;Loading MACAID 87 
2 
;;; Let's see just what that expanded into:
+ 
(MACROEXPANDED LDB 1 (LDB 603 X) (BOOLE 1 (LSH X -6) 7)) 
;;; Knowing that, observe the following:
(setf (ldb 0603 x) 5)
;Loading SETF 250 
;(BOOLE 1 (LSH X -6) 7) Obscure format - SETF

;BKPT WRNG-TYPE-ARG
;;; Hmmm...  doesn't ldb have a SETF-X property?
(plist'ldb)
;;; The property list of LDB goes here.  You cannot see it because
;;; there is a bug in DRIBBLE, but I could and it DOES have a SETF-X
;;; property.  The bug is that SETF cannot expand ANY macros until it
;;; has loaded the rest of the SETF package, because there might be
;;; SETF-X properties hidden there.  You might fix this by:
;;;  1) Loading the rest of SETF whenever you might do a macro expansion.
;;;     This is a safe solution, but it blows away your autoloading 
;;;     scheme, since the most common use of setf is with a macro,
;;;     and thus SETF would almost never be usefull in its half-loaded
;;;     form.
;;;  2) Move all the SETF-X properties on macros out of the autoloading
;;;     part of setf and put them elsewhere.  The one on LDB can be made
;;;     part of LODBYT.  This is the unsafe, hairy, bug-prone solution,
;;;     but it does preserve the silly autoloading scheme, so I bet this
;;;     is the one you will opt for.
;;;  3) Make setf be an autoloading macro, and when it autoloads
;;;     it should bring ALL of setf in.  I would do this.
;;;
;;; Now I bet you think that once this stuff is all loaded, it will work!
QUIT

* 
(setf (ldb 0603 x) 5)
;((?) (NIL)) TOO FEW ARGUMENTS SUPPLIED - APPLY

;BKPT WRNG-NO-ARGS
;;; Well that was a helpfull error message!
(errframe nil)(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))
;;; (Damned DRIBBLE!  And I'll bet that in stone-age MacLisp newio this is even
;;; a hard bug to track down!)
;;; If you could see what was in those evalframes you would be amazed that the
;;; task of groking (setf (ldb 0603 x) 5) requires that you cons up a 12-hunk!
;;; The actual error is caused by applying (lambda (()) 'x) to NIL.  Where did
;;; it get the x from I wondered?  The second argument to LDB of course!
;;; But I still cannot imagine the algorithm that makes something like this
;;; the right thing to do!