[Top][All Lists]

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

bug#20087: gensym

From: rain1
Subject: bug#20087: gensym
Date: Tue, 22 Mar 2016 11:21:05 +0000
User-agent: Roundcube Webmail/1.0.6

On 2016-03-22 05:24, Mark H Weaver wrote:
address@hidden (Ludovic Courtès) writes:
‘gensym’ returns interned symbols, but the algorithm to determine the
new symbol is simplistic and predictable.

Thus, one can arrange to produce a symbol before ‘gensym’ does, leading ‘gensym’ to return a symbol that’s not fresh (in terms of ‘eq?’), as is
the case with the second call to ‘gensym’ here:

address@hidden writes:
I agree, this goes against the main assumption people have about
gensym. I was able to reproduce the bug.

Here's a patch to libguile/symbol.c which fixes this behavior by
incrementing the gensym counter in a loop until it creates a fresh

I've considered this idea in the past, but it only avoids collisions
with symbols that have been interned before the gensym.  It does not
avoid collisions with symbols interned *after* the gensym.  Obviously,
there's no way to avoid such collisions.

Thanks for looking over the patch I sent!

One expects of gensym to create a fresh symbol, something not EQ? to any symbol that already exists. It is an important property to be able to rely on and this patch achieves that.

About symbols interned after, would that refer to something like this:

scheme@(guile-user)> (define a (gensym "x"))
scheme@(guile-user)> a
$1 = x280
scheme@(guile-user)> (eq? a (string->symbol "x280"))
$2 = #t

In most lisps gensym creates an uninterned symbol. I think that would stop the previous giving #t. I could write a patch for this if wanted.

reply via email to

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