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 <w...@sigwinch.xyz>
