Match on variables instead of expressions

[eemeli]

Closes #872
Closes #873
A rebase might be needed to deconflict test changes with #862. Edit: Done.

Submitting initially as a draft, pending final approval of the preliminary consensus noted in #873 (comment). The changes made here should be complete, though, and could be reviewed already. This PR also marks the design doc as accepted.

A consequence of changing the selector rule to be a variable rather than an expression is that the spaces around it need to now be required, rather than optional.

Another (mostly academic) interesting change is that a message starting with .match, such as

.match $x * {{...}}

is now well-formed, but not valid, as the missing annotation is considered a data model error. Complicating the syntax to make one or more declarations syntactically required for a message with variants seems unnecessary.

[aphillips]

@eemeli Thanks for starting on this.

Complicating the syntax to make one or more declarations syntactically required for a message with variants seems unnecessary.

While I tend to agree with you, the change isn't that complicated. I think it might be:

- complex-message   = [s] *(declaration [s]) complex-body [s]
+ complex-message   = [s] (quoted-pattern / (1*(declaration [s]) complex-body)) [s]

TBH, I'd rather make it a data model error.

[aphillips]

First pass.

I'm still struggling with this vs. (E) [have not yet "disagree and committed" to the emerging consensus]. I guess I'm not thrilled to have to write declarations in order to use a selector, which is why I prefer option E in the voting.

There is a certain consistency to having to declare everything you use syntactically, but that consistency breaks down later because we allow annotations in pattern expressions without declaration. I would be super-unhappy to remove that capability, because historically this has provided a kind of pattern-local documentation for translators, e.g.

You have {$n} <- $n could be anything

vs.

You have {$n :number currency=USD} <- now I know how to translate this

[aphillips]

Pending, of course, that we decide, as a working group, to accept this design as the WG consensus.

[gibson042]

I don't like the inconsistency of whitespace being required before the first match variant and optional before later ones, but it is necessary to support unquoted variant keys as in

.input{$count :number}.match $count␣1{{1 new message}}*{{{$count} new messages}}

[aphillips]

@eemeli has updated this. Propose we merge this tomorrow (2024-09-10)