Ticket 79 is one of the "correctness" category: we do something which we shouldn't (although it hasn't been seen in real life yet). When we compile a file containing 2 *different* -yet similarly named - uninterned symbols, they are coalesced into the same object when reading that fasl.
The above behaviour is a consequence of the design choice: the same uninterned symbol may occur in multiple places in the sources, meaning that multiple CompiledClosures may need to refer to the same symbol in their constructor. ABCL solved this problem by interning all unintered symbols into the same anonymous package. When that happens, all occurrances of the same uninterned symbols are coalesced into the same object.
However, the same happens to all equally named uninterned symbols which are *not* the same symbol.
Here's my idea to resolve this situation, in a simple step-by-step representation:
0. Install a dispatch macro function (in some unused dispatch macro character); something like #n# 1. Adjust DUMP-FORM to generate the dispatch output for uninterned symbols 1. Create all uninterned symbols at the start of the FASL (filling a table with them) 2. Let the reader resolve the uninterned symbols by looking up in the table
This approach has the nice side-effect that we can eliminate the need for the anonymous package - although we will need to maintain a table. It will resolve the issues we currently have with the coalesced symbols. It uses standard Lisp infrastructure; no heavy code changes required.
Comments?
Bye,
Erik.