chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Another symbol GC sanity check fix [was: R


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Another symbol GC sanity check fix [was: Re: [PATCH] Fix record type tags to be nonglobal by module-prefixing them]
Date: Wed, 19 Jul 2017 09:23:19 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On Tue, Jul 18, 2017 at 10:52:01PM +0200, Peter Bex wrote:
> Here's another attempt at improving the sanity check, but if this
> keeps cropping up we might as well just get rid of the sanity check.
> On the other hand, it does point out several issues, so maybe it's
> useful after all:
> 
> - Any symbol that starts with \x00 is seen as a keyword, which isn't
>    really true (even if unbound or bound to some other value).
>    This also has an impact on how these symbols are written.
> - This means that any symbol that was defined to itself and then
>    got its plist modified and reset would be registered as
>    collectible (because the propset would think it's a keyword)
>    even though it was still bound.
> - In general, we can't really distinguish between keywords and
>    symbols.

I think we should fix those issues some day.  For now I think (hope!
fingers crossed!) that the current situation is "good enough".
Maybe for CHICKEN 5.1 we can consider refactoring how keywords
work and make them truly distinct from symbols.

I think the basic approach would be to simply "bind" keywords to a
special value, much like we have C_SCHEME_UNBOUND we could have
something like C_SCHEME_KEYWORD (just making things up here) to
indicate unambiguously that it's a keyword.  Then, the \x00 at
the start of the name can be dropped.

This should really simplify the symbol GC and its associated sanity
check, and reduce any confusing aspects (like how keywords can
be bound to something else than themselves and still be considered
a keyword).  Instead, we can reject attempts at manipulating the
bound value of keywords and perhaps even reject plist modifications
of keywords.

From there, there are two ways to ensure they don't interfere with
symbols that are spelled the same:

- Make the lookup know what we're looking for and use the symbol's
  value to determine whether to return the object or not.
- Create a new symbol table for keywords specifically.

My preference is the second option: it's cleaner and less confusing,
and we can even experiment with a differently sized "keyword table".
This table can perhaps also be assumed to always have only weak
references.

To guarantee backwards compatibility, we could check that an interned
symbol starts with a \x00 and intern it into the keyword table.
A lookup would then also need to ignore the \x00 at the start when
hashing and searching.  Once everything is using unprefixed keywords
we can drop the special-casing for the initial \x00 value.

If people agree this is a good idea, I'll create a ticket for 5.1.

Cheers,
Peter

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]