bug#20087: gensym

[Mark H Weaver]

address@hidden writes:

> 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
>>> symbol.
>>
>> 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.

Can you give a (non-contrived) example of an application that requires
the property you stated above, but does not rely on avoiding collisions
with symbols interned after the gensym?

I’m open to the idea that such applications exist, but at the moment I
cannot think of one :)

> 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
> ------------------------

Right.  Another example would be using ‘read’ after the gensym, on input
that contains a symbol of the same name.

> In most lisps gensym creates an uninterned symbol. I think that would
> stop the previous giving #t.

Indeed, it would solve this problem, but we cannot change the behavior
of Guile's ‘gensym’ in this way, since it would break a lot of existing
code.

By the way, I looked at our manual entry for ‘gensym’, and it includes
the following text:

     The symbols generated by ‘gensym’ are _likely_ to be unique, since
  their names begin with a space and it is only otherwise possible to
  generate such symbols if a programmer goes out of their way to do so.
  Uniqueness can be guaranteed by instead using uninterned symbols
  (*noteSymbol Uninterned::), though they can’t be usefully written out
  and read back in.

We have ‘make-symbol’ for creating uninterned symbols, although you must
provide the exact name of the returned symbol.

> I could write a patch for this if wanted.

It would be nice to have another procedure, maybe ‘uninterned-gensym’
(I’m not sure what to call it, names are hard :) which would be like
‘gensym’ but would return an uninterned symbol, and thus reliably avoid
collisions.

If you’d like to contribute such a procedure, that would be welcome.

It is our policy to ask contributors to assign copyright to the Free
Software Foundation.  Would you be willing to do this?

      Mark