Consider syntax of reserved-statement some more

[eemeli]

A few issues were raised by @gibson042 in #529 (review) that we ought to consider and address:

• use of reserved-statement as interchangeable with a .match head rather than a full substitute for .match with its variants
• requiring reserved-statement to end with a list of expressions, precluding e.g. .strict true
  • ...and greedy consumption fails to capture the intuition of multiple statements in e.g. .strict true .local $var = {|val|}, instead parsing that as a single reserved statement subsuming the .local
• reusing the reserved-annotation reserved-body for reserved-statement, precluding e.g. .something opt1={$var} opt2={$var} because of the intent to prohibit e.g. nested expressions in annotations like {@reserved {|…|}}

[stasm]

@stasm:

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?

@aphillips:

I think it was me who asked for reserved-statement to potentially be also a replacement for selectors. This would allow for a different type of selector in future syntax.

Perhaps this should be:

complex-body = quoted-pattern
             / (selectors 1*([s] variant))
              / reserved-statement ; which matches some-newly-unreserved-statement 1*([s] variant) 
                                   ; for some future statement

[aphillips]

In another thread we discussed limiting reserved-statement to declarations. I have added this to the 2023-12-04 agenda.

[aphillips]

This was, in fact, discussed in the 2023-12-04 call and we landed the current syntax there. The status of that is that reserved-statement can appear in declarations but not as a replacement for complex-body (that is, there can only be .match or a quoted pattern in a complex message's body).

We said we would carry any additional discussion back to this issue, but no additional commentary has accrued.

I'm going to take the current syntax as consensus and mark this for resolve. If someone thinks we should allow non-.match statements in future syntax, they can file a new issue to that effect.