Am So., 26. Jan. 2025 um 19:02 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> Why ought I to have to pull out a random number generator – and hope I don’t lose the seed lottery – when the memory manager is perfectly capable of giving me a symbol which is guaranteed not to have the same location as any other symbol?

(1) When implemented correctly, you will not lose the seed lottery
before the end of humankind. In the meantime, all security measures
based on passphrases and biometric data on your computer have been
breached several times.

(2) Your implementation won't have to pull out any random number
generator unless you apply symbol->string, which you won't, in your
use cases.

(3) Even when using uninterned symbols, reification outside the memory
manager is necessary when you want to be able to expand your libraries
ahead of time because the expanded code must be able to refer to the
uninterned symbol in a way that identifies it across different files.
Random numbers are a reliable, simple and fast way to achieve this. Of
course, there are also other ways, but memory address won't do.

> Incidentally, if your reading of R6RS is correct in that it forbids uninterned symbols, that (a) is yet another argument that the R6RS’s ban on extensions was harmful, even beyond the bounds of the libraries it defines; and (b) means that there is, to my knowledge, not a single conformant implementation of the R6RS, because all of them have uninterned symbols.

An implementation does not become non-conformant only because it
offers an (optional) extension that diverges from R6RS semantics. This
applies to any standard or any implementation of a standard. GCC is an
implementation of ISO C (modulo bugs), though it also makes its
implementation of the GNU dialect of C accessible. R6RS even
explicitly allows unsafe libraries.

The situation is the same with, say, R7RS. Its semantics say that
(begin (set-car! x 3) (car x)) evaluates to 3. However, this may no
longer be true for an implementation offering a multi-threading
library and the user decides to use that library.

What my statement about R6RS and symbols says is that a *standard*
offering uninterned symbols and changing the meaning of `symbol=?`
could not be a compatible successor of R6RS.

NB: The definition of `symbol=?` in R7RS Small is, strictly speaking,
useless when there are uninterned symbols.

Marc

>
>
> Daphne
>
> > On 26 Jan 2025, at 17:13, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >
> > I have sketched an alternative proposal that does not need
> > uninternedness and doesn't change the semantics of symbols (as given
> > in R6RS, for example).
> >
> > You can find it here: https://github.com/mnieper/gensyms
> >
> > This proposal addresses concerns raised by Antero, John, Shiro, and
> > myself while allowing the use cases sketched by Daphne and Wolfgang.
> >
> > As it happens, the proposal can be implemented portably, given a
> > random source (e.g. /dev/random). A native implementation that creates
> > random symbol names lazily would be more efficient, though.
> >
> > Marc
>