Am So., 26. Jan. 2025 um 20:11 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 26 Jan 2025, at 19:35, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
> > On 2025-01-25 17:41 -0500, Antero Mejr wrote:
> >> Is there an intended use case that necessitates the inclusion for the
> >> :|| syntax? The SRFI says that most implementations do not offer a
> >> syntax. I think ":||" will be a bit annoying to implement in a reader:
> >> it isn't prefixed by "#", and ":" is a valid character in identifiers.
> >
> > Uninterned symbols must have a datum notation if they're to be usable
> > with datum->syntax. That's necessary, I believe, to implement the kind
> > of macros Daphne discusses in her message (at least, in the way she
> > implements them).
>
> I think the Right Thing in the absence of all other precedent would be to require uninterned symbols to print as #< unreadable objects, because read/write invariance under the datum equivalence predicate, equal?, can not be preserved, unlike for all other datums.

Yes, that's the Right Thing.

> However, since so many implementations already print gensyms either as if they were regular symbols or with some other lexical syntax, probably it is the Right Thing considering precedent to try to settle a standard lexical syntax.

I don't think precedent applies here because there is too much
difference in what is printed. Some implementations just print the
pretty name, some implementations print something that depends on
parameters, some notations apply to actually interned symbols, etc.

Precedent would also only apply in a reasonable if there were any
prior agreement in the lexical syntax. "#<bla>" is as good as ":|bla|"
in that regard.

The lexical syntax only makes this proposal worse (IMHO, of course).
Not only is the original idea of symbols (being equal if and only if
they have the same name) violated, but then also the idea that a datum
is something that has read/write invariance with respect to "equal?".

> Not having lexical syntax would indeed require adjusting the specification of procedures which take specifically a datum as argument, hmm. I’m not sure there are too many of these. Datum->syntax might in fact be the only one.

Probably. But you will lose more guarantees. For example,
syntax->datum won't necessarily return a datum object. Of course, a
redefinition of what a datum object is wouldn't cure the loss of the
guarantee. It would just be some renaming.