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.
On Sun, May 2, 2010 at 12:47 AM, Erik Huelsmann ehuels@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:
- Install a dispatch macro function (in some unused dispatch macro
character); something like #n#
- Adjust DUMP-FORM to generate the dispatch output for uninterned symbols
- 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
Hi Alessio,
On Sun, May 2, 2010 at 12:59 AM, Alessio Stalla alessiostalla@gmail.com wrote:
Here's my idea to resolve this situation, in a simple step-by-step representation:
- Install a dispatch macro function (in some unused dispatch macro
character); something like #n#
- Adjust DUMP-FORM to generate the dispatch output for uninterned symbols
- 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).
Well, I liked the idea of the terseness of the dispatch macro. That's all.
Bye,
Erik.
Alan Ruttenberg alanruttenberg@gmail.com writes:
Well, I liked the idea of the terseness of the dispatch macro. That's all.
What if some user similarly likes it? Can what your propose interfere with a legal use extension?
-Alan
As it's about the fasl format, user reader macros have long been gone at that time.
I think the older issue, where using reader tricks caused problems (which you may be recalling), was that LOAD didn't properly set up the readtable it used, but the possibly user-modified *readtable* was used.
-T.
Hi Alan,
On Sun, May 2, 2010 at 2:03 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Well, I liked the idea of the terseness of the dispatch macro. That's all.
What if some user similarly likes it? Can what your propose interfere with a legal use extension?
This would happen in a separate readtable (one which is never bound to *readtable*), which is indeed past any compile-time macro processing. User-defined :load-toplevel switching of readtables will also still be supported.
I guess that is the more technical variant of Tobias' answer.
Bye,
Erik.
On Sun, May 2, 2010 at 3:38 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alan,
On Sun, May 2, 2010 at 2:03 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Well, I liked the idea of the terseness of the dispatch macro. That's all.
What if some user similarly likes it? Can what your propose interfere with a legal use extension?
This would happen in a separate readtable (one which is never bound to *readtable*), which is indeed past any compile-time macro processing. User-defined :load-toplevel switching of readtables will also still be supported.
Thanks. For better or worse, it seems macro processing is *never* gone in lisp, with load-time-value and eval-when's possibly calling (or causing to have called) read, and I've been burned by my own lack of consideration of possible other system use of the reader macros I've defined.
-Alan
I guess that is the more technical variant of Tobias' answer.
Bye,
Erik.
Alan Ruttenberg writes:
Thanks. For better or worse, it seems macro processing is *never* gone in lisp, with load-time-value and eval-when's possibly calling (or causing to have called) read, and I've been burned by my own lack of consideration of possible other system use of the reader macros I've defined.
For the latter matter, are you aware of named-readtables? They provide a namespace for readtables like there's a namespace for packages, so that systems can hack the reader to oblivion without stomping on each other feet. The code is pretty much portable except for working around some implementations' idiosyncracies. Should work on ABCL just fine.
-T.
PS.
On Sun, May 2, 2010 at 2:00 PM, Tobias C. Rittweiler tcr@freebits.de wrote:
For the latter matter, are you aware of named-readtables? They provide a namespace for readtables like there's a namespace for packages, so that systems can hack the reader to oblivion without stomping on each other feet. The code is pretty much portable except for working around some implementations' idiosyncracies. Should work on ABCL just fine.
I can confirm it works on ABCL, and it's a great piece of software. I use it in my "Snow" library.
Alessio
On Sun, May 2, 2010 at 12:47 AM, Erik Huelsmann ehuels@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.
Proposed change committed in r12650. Ticket #79 is now fixed!
Code changes were a little bit more involved than I had planned, but *fasl-anonymous-package* was used in more places than I expected.
As a consequence of this change, I have increased the FASL version number.
Bye,
Erik.
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Erik Huelsmann -
Tobias C. Rittweiler