[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AAIIEEE!!!!!! shit for brains!
- To: BUG-LISP at MIT-MC
- Subject: AAIIEEE!!!!!! shit for brains!
- From: Alan Bawden <ALAN at MIT-MC>
- Date: Thu, 18 Sep 80 06:03:00 GMT
- Original-date: 18 September 1980 02:03-EDT
;;; In a fresh lisp (version 1997)
(setq x 222222)
(ldb 0603 x)
;Loading LODBYT 24
;Loading DEFMAX 44
;Loading MACAID 87
;;; 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
;;; Hmmm... doesn't ldb have a SETF-X property?
;;; 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
;;; 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!
(setf (ldb 0603 x) 5)
;((?) (NIL)) TOO FEW ARGUMENTS SUPPLIED - APPLY
;;; 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!