On 07/23/2012 06:40 PM, Alessio Stalla wrote:
On Mon, Jul 23, 2012 at 6:48 PM, Durward McDonell durward.mcdonell@jhuapl.edu wrote:
Hello.
I believe I have found a bug in FASL loading, with respect to *read-base* being reset. At least, I get the behavior I expect in sbcl, and not in abcl.
Consider the following code:
(defmacro foo-bar (s) `(sublis '((foo . bar)) ,s))
(defun foo-bar-rb () (let ((*read-base* #x10) (it (read))) (eval it)))
Load this code, then execute (foo-bar-rb). It will wait for input. Type (foo-bar '(foo)). I would expect this to evaluate to (bar), but abcl gives a FASL version mismatch, where it seems that it is reading the FASL in the new base (16 instead of 10), and reports "found '56' but expected '38' in sublis".
Hi!
What FASL are you speaking of? There is nothing explicitly loading one in your code. Is this related to autoloading?
Yes. What I think is happening (and I could be wildly wrong) is that sublis is not loaded until it is called in the eval, where *read-base* has been reset to #x10. Then, when the fasl with sublis is autoloaded, it reads the FASL version number in base 16 and gets the wrong value, and fails. In fact, if you do the following, it works:
CL-USER> (load "foo-bar.lisp") T CL-USER> (sublis '((x . y)) '(x)) (Y) CL-USER> (foo-bar-rb) (foo-bar '(foo)) (BAR) CL-USER>
I assume this is because calling sublis is causing it to be autoloaded (with the expected *read-base*), and then it doesn't have to be loaded again when eval is called.