the [/] is super-subtle and may be worth a comment. These are there to make the empty string a valid message.

I agree, let's make sure this is called out in syntax.md.

It may prove valuable to establish a greater separation between selectors and reserved-statement here.

Could you say why? The two expressions are wholly synonymous, and I don't really see why we should prefer one over the other.

Because I expect the latter to diverge—I don't think we should treat .match {…}… and .<reserved> … as interchangeable prefixes before a list of variants, but rather .match {…}… <variant>… as one thing complete in itself and .<reserved> … as something independent.

What's the motiviation for putting reserved-statement inside complex-body? Do we expect other multivariant constructs than match? I think this may be building too much flexibility into the spec. Could we instead agree that any future keywords would go with other declarations?

Ah, I now see that @gibson042 mentions this as one of the issues to work on as follow-ups in his review. How about we land this PR without reserved-statement in complex-body and then consider adding it, rather than landing it with doubts?

Tbh, I would find it easier to include it, show what impact it has across the stack, and then evaluate whether to drop it.

We have already agreed on having two follow up PRs to this that will both re-tread this ground. Could we agree that this will be considered more in both of those, and accept having it in the ABNF for now?

Tbh, I would find it easier to include it, show what impact it has across the stack, and then evaluate whether to drop it.

We should do things exactly the other way.

I also don't appreciate pushing hard for merging. We should merge when things look good to merge.

Nit: it looks like we don't append -char to other -start productions in our grammar.

Note that there already is another rule that's called simple-start. If necessary, could we take care of any such editorial rule renames in a separate follow-up PR?

Ah, I see. I'll open a new PR for this.

Replying to @gibson042 from #529 (comment):

Please correct me if I misremember, but my understanding from today is that we're fine with reserving only statements that end in an expression?

That is not my recollection, and would preclude possibilities like .strict true. However, I'm fine with addressing it in a followup.

Could we merge this PR with this note in the ABNF, in expectation of getting a PR from @gibson042 that could update all reserved content holistically?

ps. I had not considered statements like .strict true. That does sound like something we ought to reserve space for.

The reason statements end with expression is that the closing } of the expression is how we know the statement ended. Otherwise we're in reserved-body... forever. It is a hidden detail of our syntax that statements end with a close bracket.

While that's true with the current state of this PR, I believe @gibson042 would like us to drop . as a valid character in reserved-body, which would allow determining its end by encountering it at the start of the next keyword.

My request here is for us to find a way to not block this PR on that discussion, and to have it instead separately so that the syntax of both reserved statements and annotations could be considered in one package.

I agree with finalizing this PR. I don't think the reserved-statement discussion (were we to change something) needs to be in the way of that. It should be a separate conversation. If we want to pursue a change, it should be at least an issue if not a design document.

That said, I would not include the proposed note in this comment thread. Any changes we consider or make will be done in the near future. If we include text about it, put it in syntax.md.

There should be separate productions for reserved statement bodies and reserved annotation bodies, so the body of reserved/private-use annotations better aligns with that of function annotations.

reserved-char should omit . so e.g. .new {$a} .hotness {$b} is recognized as two distinct reserved statements and .prefix {$foo} .local $var = {|val|} is recognized as a reserved statement followed by a local declaration, while still allowing reserved statements to include non-consecutive expressions (like local-declaration = local s variable [s] "=" [s] expression already does).

And accordingly, reserved-escape should be generalized to e.g. reserved-statement-escape = backslash ( %x00-D7FF / %xE000-10FFFF ).

Note that this precludes syntax like that used now in local-declaration, where we have a variable name at the top level, and name can include a .. Is that intentional?

No, it will need further tweaking to match . only after name-start or name-char, as inside name.