Marc:

On 2025-01-24 13:53 +0100, Marc Nieper-Wißkirchen wrote:
> 1. The existing language already has plenty of other methods to create
> objects that are not `eq?` to any existing object. This has already
> been observed by John.

Agreed. There's no real reason to use uninterned symbols instead of
strings in ordinary programming.

> 2. The only use case given in the SRFI is macro programming (for
> communicating between procedures, any other objects besides symbols
> can be used). However, the SRFI fails to give an example that can be
> critisied.

If you and Daphne agree, I'll include Daphne's oddly-named
communicating macros example, and your alternative solution, in the
next draft.

> 3. The semantics of the language become more complicated and less
> pleasant. The earlier possible invariant that symbols have read-write
> invariance would no longer be possible. The reason d'ètre of symbols
> would be gone.
>
> [snip]
>
> To make it precise that uninterned symbols are unique, this SRFI will
> need some language saying that uninterned symbols are conceptually
> tagged with a location or similar.

This is indeed the worst part of adding uninterned symbols to the
language. I am mostly convinced that SRFI 260's generated symbols do
everything that we want uninterned symbols for, and that they can do
it without changing Scheme's notion of a symbol.

On the whole, I'm not sure what I want to do with SRFI 258. Uninterned
symbols are widely implemented, and the SRFI may be useful to
implementers who want to include them. On the other hand, do I want to
Request that they be Implemented? Not really; not if we can have
interned symbols that are just as good.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>