Erik Huelsmann ehuels@gmail.com writes:
The other day, Alessio and I were talking about how unfortunate it is that we use the reader to create relatively simple structures, such as lists in our Java classes. To illustrate:
(defun foo () (let ((x '(1 2 3))) x))
In the above definition, if being file-compiled, the litteral list (1 2 3) gets serialized into a string which is - at load time - converted back to an object like this:
LispObject theObject = Lisp.readObjectFromString("(1 2 3)");
In our minds, it would be faster to generate:
LispObject theObject = new Cons(new Fixnum(1), new Cons(new Fixnum(2), new Cons(new Fixnum(3)))));
Because that eliminates the need to set up a stream, reading from a string, running all the characters through the reader, including running of dispatch functions, etc.
While that would be a nice optimization, I've run into a correctness issue investigating our current serialization.
Now consider the following macro:
(defmacro foo (x) `(defun bar () (let ((a ,x) (b ,x)) (eq a b))))
(foo '(1 2 3))
This macro can be used to generate an example of 2 objects sharing structure to the extreme: they are the same object. The same object is supposed to be assigned to A and B. In the interpreter, the result of a function call to BAR returns T. However, after filecompiling the above forms and loading the resulting fasl, the outcome of BAR is NIL.
Suddenly, the forms are not the same anymore. The answer to that is too simple: the object assigned to A and B is being read for A and B separately with a readObjectFromString call, like this:
LispObject theObjectA = Lisp.readObjectFromString("(1 2 3)"); LispObject theObjectB = Lisp.readObjectFromString("(1 2 3)");
The above is clearly wrong. The solution to this case is very simple: we should detect "duplicates" being serialized by the DECLARE-OBJECT-AS-STRING function.
Why wrong? Literal coalescing is optional behaviour as far as I remember.
-T.