Uninterned symbols #70

mnw commented 2022年04月14日 13:24:28 +02:00

They haven't been standardized in small nor in earlier reports. The large language may want to introduce them. They can be useful for implementing a variety of things, e.g. the colors/marks of the syntax-case expansion algorithm.

They would be most useful if they would also obey read/write invariance. This can be achieved if the implementation associates a UUID to each of them and given them a written representation, e.g. in Chez's form #{<pretty name> <uuid>}.

Technically, this wouldn't make them uninterned anymore. They would be symbols interned by their UUID and not their name.

They don't necessarily have to be a subtype of symbols but could be their own type, but this would probably be a novelty among most existing implementations.

The Foundations would have to provide at least (gensym [<string>]) and (gensym? <obj>) together with the definition of an external representation.

Alternatively to the above, (gensym) could just return an ordinary symbol whose name is random in the sense of Version 4 UUIDs. In that case, there would be no gensym?.

They haven't been standardized in small nor in earlier reports. The large language may want to introduce them. They can be useful for implementing a variety of things, e.g. the colors/marks of the syntax-case expansion algorithm. They would be most useful if they would also obey read/write invariance. This can be achieved if the implementation associates a UUID to each of them and given them a written representation, e.g. in Chez's form `#{<pretty name> <uuid>}`. Technically, this wouldn't make them uninterned anymore. They would be symbols interned by their UUID and not their name. They don't necessarily have to be a subtype of symbols but could be their own type, but this would probably be a novelty among most existing implementations. The Foundations would have to provide at least `(gensym [<string>])` and `(gensym? <obj>)` together with the definition of an external representation. Alternatively to the above, `(gensym)` could just return an ordinary symbol whose name is random in the sense of Version 4 UUIDs. In that case, there would be no `gensym?`.

dpk commented 2022年04月15日 12:09:15 +02:00

I’ve previously (c. 2010, I think?) experimented with gensyms with read-write invariance, using a UUID-like solution, and found them pretty useless. (I intended them to be useful for sending data including gensyms across a Unix pipe between two Lisp processes. This turned out not to be worth the trouble.)

In general I think we should not standardize them. Even if they’re useful for implementing generate-temporaries, that’s an implementation detail. (I guess you could use them to implement marks as well.)

There are a couple of other things I’ve used gensyms for in other Lisps, e.g. as a sentinel value in certain algorithms/data structures signalling a special case. In Scheme I currently do this by consing a pair and checking for it with eq? to handle the special case (cf. how Chibi handle multiple values), but I intend to propose a SRFI for ‘sentinel objects’ — values with no contents and no semantics other than equality, and by extension whatever meaning a program attaches to their existence or presence in a certain context.

I’ve previously (c. 2010, I think?) experimented with gensyms with read-write invariance, using a UUID-like solution, and found them pretty useless. (I intended them to be useful for sending data including gensyms across a Unix pipe between two Lisp processes. This turned out not to be worth the trouble.) In general I think we should not standardize them. Even if they’re useful for implementing `generate-temporaries`, that’s an implementation detail. (I guess you could use them to implement marks as well.) There are a couple of other things I’ve used gensyms for in other Lisps, e.g. as a sentinel value in certain algorithms/data structures signalling a special case. In Scheme I currently do this by consing a pair and checking for it with `eq?` to handle the special case (cf. how Chibi handle multiple values), but I intend to propose a SRFI for ‘sentinel objects’ — values with no contents and no semantics other than equality, and by extension whatever meaning a program attaches to their existence or presence in a certain context.

mnw commented 2022年04月15日 12:23:49 +02:00

What do you mean by "not worth the trouble"? Where's the trouble?

In your use case, you may have found them pretty useless but this observation certainly does not extend to other users.

If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them.

Gensyms are indeed not needed for your sentinel objects, but that's not why I am proposing them here.

What do you mean by "not worth the trouble"? Where's the trouble? In your use case, you may have found them pretty useless but this observation certainly does not extend to other users. If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them. Gensyms are indeed not needed for your sentinel objects, but that's not why I am proposing them here.

johnwcowan commented 2022年04月16日 03:56:15 +02:00

If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them.

If you really mean that, it is an abdication of responsibility. CL's TAGBODY meets these requirements, and cab even be implemented in syntax-rules using tail recursion (which CL does not have): should it therefore be included in R7RS-large, much less the foundation language? I think not. And that is just one of thousands of such things.

> If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them. If you really mean that, it is an abdication of responsibility. [CL's TAGBODY](http://clhs.lisp.se/Body/s_tagbod.htm) meets these requirements, and cab even be implemented in `syntax-rules` using tail recursion (which CL does not have): should it therefore be included in R7RS-large, much less the foundation language? I think not. And that is just one of thousands of such things.

mnw commented 2022年04月16日 08:12:18 +02:00

If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them.

If you really mean that, it is an abdication of responsibility. CL's TAGBODY meets these requirements, and cab even be implemented in syntax-rules using tail recursion (which CL does not have): should it therefore be included in R7RS-large, much less the foundation language? I think not. And that is just one of thousands of such things.

You can't view an argument in isolation.

In the actual case at hand, my argument goes as: if they weren't cheap to implement, that could be a reason not to implement them, despite their well-founded benefits and usefulness to some users and use cases.

> > If they are cheap to implement, their semantics are clear and they are easy to spec, there's no reason not to ship them. > > If you really mean that, it is an abdication of responsibility. [CL's TAGBODY](http://clhs.lisp.se/Body/s_tagbod.htm) meets these requirements, and cab even be implemented in `syntax-rules` using tail recursion (which CL does not have): should it therefore be included in R7RS-large, much less the foundation language? I think not. And that is just one of thousands of such things. > You can't view an argument in isolation. In the actual case at hand, my argument goes as: if they weren't cheap to implement, that could be a reason not to implement them, despite their well-founded benefits and usefulness to some users and use cases.

johnwcowan commented 2022年05月06日 18:21:44 +02:00

In Scheme I currently do this by consing a pair and checking for it with eq? to handle the special case

That certainly works fine; for myself, I prefer (define sentinel (string-copy "sentinel")).

See #71 for my discussion of cheap UUIDs.

> In Scheme I currently do this by consing a pair and checking for it with eq? to handle the special case That certainly works fine; for myself, I prefer `(define sentinel (string-copy "sentinel"))`. See #71 for my discussion of cheap UUIDs.

phm commented 2026年05月01日 16:36:17 +02:00

The group voted on 2026年04月30日 to not include either SRFI 258 or SRFI 260.

The group voted on 2026年04月30日 to not include either SRFI 258 or SRFI 260.