On 30 Jul 2021, at 01:34, John Cowan <xxxxxx@ccil.org> wrote:

> In "Keyword datums",  the introduction says "three categories", but there are four.  (I use "the following categories" in this situation to avoid such problems.)

Fixed for the next draft.

> More importantly, Racket is a fifth type, close to your third type but not self-quoting in general, only when used in a function call.

Hmm, yes, you’re correct. But I think it’s still at least a subtype of third variety. I’ll note it.

> A macro can't figure out if #!fold-case is in effect, because case folding is done at read time, not at macro expansion time.

I have changed ‘case-sensitive’ to ‘case-folded’; the specification already notes that this takes effect at the read-time of the macro rather than expansion time. It’s more intended to acknowledge the standard behaviour, rather than creating a special case of it; but also that in the case of Racket and Kawa, if (: …) were to be the final R7RS Large solution for keyword datums, it might make more sense for them to special-case it at read time. But I notice now that that creates an even deeper semantic hole of compromises whose implications are still not fully considered in the document, sigh.

> In R7RS, :|123| is always going to be indistinguishable from |:123|; this has nothing to do with keywords being disjoint or not.

*In*distinguishable? At present, the former in Chibi gives me a symbol which the writer gives back out as |:\|123\||; |:123| is a symbol :123.

That sentence in any case is part of the compromised nature of the minimal compatible proposal, connected to the penultimate point on the behaviour of keyword datums (undefined whether `symbol?` is #t or #f), intended to suggest a way for existing implementations to change their current behaviours as little as possible to support R7RS, if R7RS does have a lexical notation for keywords (whether that is prefix or postfix colons or something else). I hope our eventual solution to keyword arguments in general will not be as compromised as my proposals.

> Compiler macros, identifier-syntax, and syntax-case are three different things.  The first distinguishes between running in the compiler and the interpreter, a concept alien to Scheme.

In the context of Common Lisp, yes. But I explicitly give my own definition of it which doesn’t make that distinction, instead talking more generally about allowing procedures to perform macro-like transformations at their call site for optimization reasons, without *becoming* macros and losing their first-class status.

I have amended the sentence in question for the next revision to make it clearer that I am using an adapted definition.

> Identifier-syntax always behaves the same way whether in operator or operand position.  So it is syntax-case alone that can provide this behavior.

I think this is conflating things. If we adopt explicit renaming only, we can still specify identifier syntax with the behaviour needed, albeit (as I recently mentioned to Marc) no existing explicit renaming system actually does this at present, to my knowledge.

identifier-syntax, all lower-case and with hyphen, is a high-level feature in R6RS which indeed only allows defining macros such as you say, with the same behaviour everywhere. Identifier syntax in general, sentence case and without hyphen, allows identifiers to be matched and transformed as macros outside of first position — regardless of whether it is implemented by syntax-case or explicit renaming or syntactic closures, or just allowed in plain syntax-rules patterns with no indication of how it’s implemented (R7RS small could have done this, but didn’t). In particular, the lower level system will always be able to detect which of the two contexts a macro keyword has been used in and transform appropriately, because it will likely be used to implement both the high-level syntax-rules and high-level identifier-syntax features. I would appreciate a suggestion for a better and less confusing name for the latter feature. (Generalized macros? Position-agnostic syntax keyword matching/expansion?)

> MN-W was able to retrofit it into syntax-rules, but it's not portable to do so.  Here's what that looks like:
>
> (define-syntax foo
>   (syntax-rules ()
>     (foo (foo-operand))
>     ((foo obj ...) (foo-operator obj ...))))

I don’t understand this. Is there a link for M N-W’s implementation of whatever this is? R6RS syntax-rules can do this too, because it's nothing more than a simple wrapper around R6RS syntax-case, although I think the clauses have to the in the opposite order to your example or the latter one will never match.

> Default vs. no-default keywords:  the signature of CL's `make-array` is (make-array dimensions &key adjustable fill-pointer displaced-to displaced-index-offset element-type initial-element initial-contents).  Of these, all have defaults except the last two, or perhaps it is more accurate to say the default is implementation-specified.  But it is definitely not nil, because filling the array with nils is not the same as not filling the array.

Are you saying that in CL, if I pass nil explicitly to all those keyword arguments of make-array, it has a different effect to if I’d omitted them?

> Note that in addition to &allow-other-keys in a lambda list, there is also :allow-other-keys <boolean> in a function call, which causes unknown keys to be silently ignored; it is most often used in `apply`, but can be used in any function call.

I will mention it, but I don’t think even Guile supports this in Scheme. What’s the intended use?

Many thanks for the helpful input,

Daphne