Per and Vincent, thank you for your comments.

I would like to leave it truly open for an implementation to use a
special initial character or not. As a generated symbol cannot be
mistyped anyway due to its sufficiently random name, a special initial
character is not needed for that purpose but would only make a
difference in printing.

A special initial character would make it easy to spot that a symbol
appearing in the output is very likely to be a generated one, which
can be an advantage of generated symbols. On the other hand, symbols
with special initial characters will be written as |??...| (R7RS) or
\x??;... (R6RS), which is not particularly pretty and may make it
harder to read S-expressions with many generated symbols (e.g. the
output of some compiler stage).

I prefer the second advantage; some will prefer the first (as
suggested by Per), so the SRFI should probably remain silent about it.

Am Di., 28. Jan. 2025 um 00:49 Uhr schrieb Vincent Manis (he/him)
<xxxxxx@telus.net>:
>
> On 2025-01-27 15:19, Per Bothner wrote:
>
> > Perhaps require (or at least recommend) that generate-symbol contain
> > at least
> > one character that is neither an <initial> or a <subsequent>?
> > I.e. at least one character that can only be written with an <inline
> > hex escape>
> > or a <mnemonic escape> or <whitespace>? (I suggest a space.)
>
> I support this SRFI.
>
> I'm quite happy with leaving the name implementation-defined (as long as
> write or display includes a recognizable rendition of the pretty-name).
> If there is a requirement for a non-identifier character, I would oppose
> the space, as (misguided) use of display would produce misleading
> output, but I don't see a need for it. I've already stated elsewhere
> that if I were to implement generate-symbol, I'd use UUIDs (and possibly
> a counter), and it would be almost impossible to enter a similar symbol
> manually.
>
> I haven't looked at the sample implementation, but since it uses
> /dev/random, a note mentioning the Windows library routine rand_s, which
> is (supposedly) similar, would not go awry.
>
> -- vincent
>