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.

I think requiring reserved-statement to end with at least one expression matches too little.

Note that this locks in the expression syntax for effectively forever because a left brace could start a {{…}} quoted expression which would terminate the reserved statement—though possible to work around that too; it's rather impractical. And likewise for quoted.

The . exclusion also disallows using name within a future statement, so e.g. introducing local-declaration would not be possible if we didn't include it already.

On the other hand, if each declaration had to end in a required whitespace s, we would only need to bar the sequence (s ".") from what's reserved.

@gibson042 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?

@gibson042 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.

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.

@gibson042 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.

This fails to allow whitespace between the terminal expressions, and more importantly suffers from the reserved-body problem mentioned below.

Is there any particular benefit to parsing out the spaces within reserved content? Originally in #374 (comment) we took them out of reserved-char to effectively trim the reserved expression contents within the ABNF.

Should we perhaps revisit that decision, and simplify some of this by not splitting the reserved text into parts?

In the meantime, good point about the missing [s] between expressions. If we leave the reserved cleanup to later, this should work for the current line:

Is there any particular benefit to parsing out the spaces within reserved content? Originally in #374 (comment) we took them out of reserved-char to effectively trim the reserved expression contents within the ABNF.

I think there is; it allows us to more accurately capture adjacency, especially when it comes to things like consecutive declarations (ok but should remain separate) and directly adjacent quoted literals (should be rejected IMO) and—as you mentioned in another comment—dots, which should be accepted as part of a name but not when they appear to start a new statement.

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.

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.

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?

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.