Hm, drat. This "fix" means that we have to be more careful with code that coerces symbols to strings and back, like fallintothis's 'sscontract.
I think I prefer original Arc's gensym hack for the time being, since I know that as long as I don't begin any symbols in my own code with "gs", they won't share their name with any gensyms.
With Anarki's approach, wouldn't it be harder to accomplish serializable gensyms? In official Arc, this kind of thing might be done on the reader side by replacing all read-in symbols that start with "gs" so that they don't conflict with gensyms currently in use. In Anarki, uniq!g1 and (uniq) can return gensyms with the same name, so there would have to be some special behavior on the writer side too.
To give a clearer example of what I'm talking about, a Racket-style serialization format would probably look something like this, where #u:X does what it can to create a new, uninterned X every time it's read in (and specifically works when X is a symbol):
I suspect that if we want to be able to produce unique symbols that can be serialized, we should use random symbols of sufficient length that the chance of collision is vanishing small (that is, similar to a UUID or GUID).
While a #u:X approach would work for a single output, if I produce multiple output files I have no reliable way to put the same uninterned symbol in different files.
Right, but I wasn't familiar with it. This time, I thank you for pointing it out for me. ^_^
I meant to convey that I'd rather write Arc code so that sentinel values are generated using [] or whatnot, rather than introducing uninterned symbols to the language. Uninterned symbols make it much less of a pain for multiple threads to generate unique variable names, but they introduce complexity in other places. Besides the hypothetical examples I already mentioned, I'm happy I can enter (uniq) symbols at the REPL when I'm debugging.
I don't really expect this opinion to catch on, but I'm throwing it out there just in case.
