[Top][All Lists]

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

Re: Release 1.6 critical TODO items.

From: Martin Grabmueller
Subject: Re: Release 1.6 critical TODO items.
Date: Mon, 28 Jan 2002 10:26:00 +0100

> From: Rob Browning <address@hidden>
> Date: Fri, 25 Jan 2002 16:19:54 -0600
>   - We must fix gensym -- right now at startup (eq? 'g0 (gensym)) is
>     true.  This pretty much defeats the purpose of gensym :>
>     Marius: I remember you had said something about fixing this by
>     creating symbols that were unaccessable -- is that something you'd
>     have time to do soon, or could you tell one of us how to fix it?
>     Also, could whoever fixes this add appropriate tests, if there are
>     any (probably depends on the nature of the fix) to make check?

Some time ago, I have proposed a simple fix: Provide a function
scm_mem2uninterned_symbol (sketched below) which is the same as
`scm_mem2symbol', but does not consult the symbol table before
creating the symbol (attention, untested...).

scm_mem2uninterned_symbol (const char *name, size_t len)
  size_t raw_hash = scm_string_hash ((const unsigned char *) name, len);
  size_t hash = raw_hash % SCM_VECTOR_LENGTH (symbols);
    SCM symbol;
    SCM cell;

    SCM_NEWCELL2 (symbol);
    SCM_SET_SYMBOL_CHARS (symbol, scm_must_strndup (name, len));
    SCM_SET_SYMBOL_HASH (symbol, raw_hash);
    SCM_SET_PROP_SLOTS (symbol, scm_cons (SCM_BOOL_F, SCM_EOL));
    SCM_SET_SYMBOL_LENGTH (symbol, (long) len);

    return symbol;

Then this would be used in `scm_gensym' instead of `scm_mem2symbol'.
Symbols created with would then be unique.

IRIC, the problem with this was that after writing out/reading in, the
gensym symbols would not be unique anymore.  After looking for a
solution for that, we came into a larger discussion about read/write
invariance, cyclic data structures, symbol->string conversions etc.


reply via email to

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