While this makes sense from a DRY point of view, I left out this optimisation because I don't think "operand" is an appropriate term for the value of an option: #395 (comment).

While this makes sense from a DRY point of view, I left out this optimisation because I don't think "operand" is an appropriate term for the value of an option: #395 (comment).

I see your point. Perhaps something like:

expression = "{" [s] ((atom [s annotation]) / annotation) [s] "}"

option = name [s] "=" [s] atom

atom = literal / variable

Or even, to keep the term "operand" around for clarity:

expression = "{" [s] ((operand [s annotation]) / annotation) [s] "}"

option = name [s] "=" [s] atom

operand = atom
atom = literal / variable

Why make the change? It's not crucial, but when working on #402, I found it awkward to express this text. I wanted to be able to say that when a variable appears in an operand context, the variable's name must already be in scope. But to be precise, the text has to say "when a variable appears as an operand or as the variable in an option", which is verbose. If option also referred to operand, it would be simpler. The same situation might arise elsewhere in the spec.

An alternative that helps with the exposition in #402 is to change the grammar to distinguish variable references from variable definitions. But even if we also made that change, I could imagine it being useful to write "in an atom" instead of "in an operand or in the literal or variable of an option.

(I prefer to avoid "value" since if value was a non-terminal in the grammar, that clashes with the concept of a semantic value (resolved value). A variable would be an example of a value in the grammar, but would not be a resolved value in the semantics, which I think is potentially confusing.)

An alternative that helps with the exposition in #402 is to change the grammar to distinguish variable references from variable definitions. But even if we also made that change, I could imagine it being useful to write "in an atom" instead of "in an operand or in the literal or variable of an option.

As we discussed in #393 (comment) regarding the data model, I agree that the left-hand side of a declaration should be called something different than the places where we're using variable to look up its value.

At its simplest, it could be just

declaration = let s "$" name [s] "=" [s] expression

but including an intermediate construct like your proposed variable-definition would also work.

It would be easier to continue consideration of whether something like atom ought to be introduced after this change.

Some (experimental) prior work:

• In stasm/message2, I used Operand for all occurences of "literal or variable", including option values: https://github.com/stasm/message2/blob/4abf43f2023b6e20d8ee1d462684d0741ece791b/syntax/ast.ts#L58
• In ICU4J, @mihnita used Value for the same concept: https://github.com/unicode-org/icu/blob/e8bc04d5dfd4a463608ccbb47efca7de222d66a5/icu4j/main/classes/core/src/com/ibm/icu/message2/Mf2DataModel.java#L476

close per discuss in wg call. may reopen in the future based on discussion of semantics for "value"