Am So., 26. Jan. 2025 um 20:11 Uhr schrieb Daphne Preston-Kendal <[email protected]>: > > On 26 Jan 2025, at 19:35, Wolfgang Corcoran-Mathe <[email protected]> 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.
