'(#B10 10)

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

    Date:  7 APR 1981 0515-EST
    From: WGD at MIT-MC (William G. Dubuque)
    In MACLISP 2077 with SHARPM 72 and BASE = IBASE = 10, *NOPOINT = ()
    '(#o10 10)  ==>  (8. 8.) !
    --------
    Date:  7 APR 1981 1409-EST
    From: kmp at MIT-MC (Kent M. Pitman)
    Subject: more on base
    '(10 #8r10 10) => (10. 8. 8.)
    '(10 #2r10 10) => (10. 2. 2.)
    '(10 #o10 #.(print (list 'ibase= ibase 'base= base)) 10)
    (IBASE= 10. BASE= 10.)
     => (10. 8. T 10.)
    Maybe something about #. is re-initializing things... 
Ha, TYIPEEK is the villain!  It clobbers the variable used to hold both 
a "reason" why TYI is called and the "re-entrancy level" of a call to read 
-- BFPRDP.  Aparently whoever put this variable into the reader is not the 
same person who used it in TYIPEEK.  Anyway, TYI and other functions interact 
with it correctly, so I've edited the source to have TYIPEEK save-and-restore 
this variable, just like the others.
    At first RLB and I thought it was merely the fact that the reader was 
"cache"ing the error-checked value of IBASE upon main entry, so I patched 
a lot of save-and-restore around reader macro calls into the current LISP 
dump.   But upon closer inspection, I discovered that BFPRDP had the wrong 
value when the SHARPM function for radix reads was calling READ (re-entrantly,
of course).   Here is an example which shows TYIPEEK to be the villain:

;;Run this in OLISP^K to see the effect of the bug.
(defun RR () 
   (let ((IBASE (caseq (tyi) 
		  ((#/X #/x) 16.)
		  ((#/O #/o) 8)
		  ((#/B #/b) 2)
		  (T (tyipeek) 
		     (* 2 IBASE) ))))
     (read)))

(setsyntax '/! 'macro 'RR)
(setq BASE (setq IBASE 10.))

'(!O10 10)
'(!X10 10)
'(!D10 10)
'(!B10 10)