[armedbear-devel] Idea to fix ticket 79: identical uninterned symbols coalesced in fasl

[Alessio Stalla]

On Sun, May 2, 2010 at 12:47 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
> 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?

Sounds like a good plan. However, probably a custom reader macro can
be avoided in favor of something like #.(sys::fasl-uninterned-symbol
key-in-the-table).

Bye,
Alessio