Update the rest of the spec to match the ABNF after adding .keywords

[eemeli]

This applies the changes from #529 to the rest of the specification (syntax, data model, formatting).

The ABNF is also updated editorially to include the placeholder and matcher described in the syntax.

A new Unsupported Statement error is added.

The data model changes also account for the change from let to local and input, which was not previously done.

[gibson042]

For consistency with the data model implied by the grammar, func fields should probably be renamed (and possibly FunctionExpression as well, in both the grammar and here).

Suggested change

	type Expression = LiteralExpression | VariableExpression | FunctionExpression;
	interface LiteralExpression {
	arg: Literal;
	func?: FunctionRef | UnsupportedExpression;
	}
	type Expression = LiteralExpression | VariableExpression | AnnotationExpression;
	interface LiteralExpression {
	arg: Literal;
	annotation?: FunctionRef | UnsupportedAnnotation;
	}

etc.

[eemeli]

One challenge with "annotation" is that when it's in an expression without an operand, what is it "annotating"?

[aphillips]

The expression.

[eemeli]

To me this sounds rather tautological. I'd be happy for us to discuss this naming briefly during tomorrow's call, and to go with whatever the majority prefers (as in, spend max 5 min and either reach a conclusion or continue from there async).

[aphillips]

If you glance at the agenda you'll notice that I have a bunch of these short highly timeboxed issues for tomorrow. I've added this one.

---

I'll note that the current ABNF uses the term function-expression and the data model should basically match the ABNF word-for-word to the extent possible. Keeping FunctionExpression seems fine?

I do think that this might not be right, though:

  annotation?: FunctionRef | UnsupportedAnnotation;

UnsupportedAnnotation applies to reserved-annotation but not necessarily to private-use-annotation. Private use is only supported if the implementation says it is. So we need a third bucket for private use to go into so that implementations that support the PU can consume it, e.g.:

  annotation?: FunctionRef | PrivateUseAnnotation | UnsupportedAnnotation

(it is possible for a private-use to be unsupported)

[eemeli]

For the cases where the implementation does support a specific private-use annotation, we have this:

message-format-wg/spec/data-model/README.md

Lines 167 to 171 in f359856

	When parsing the syntax of a _message_ that includes a _private-use_ _annotation_
	supported by the implementation,
	the implementation SHOULD represent it in the data model
	using an interface appropriate for the semantics and meaning
	that the implementation attaches to that _annotation_.

And then in the Extensions section, we specify that an implementation is allowed to extend the data model for that purpose. Or at least it's intended to do so.

So we can at this point lump all of the unsupported reserved & private-use into this one basket of the data model, rather than needing to split it as in the syntax.

[aphillips]

If the data-model is meant to be interchanged, does that mean that the "private-use-ness" might be a relevant detail to the consumer? I mean, maybe it's FunctionRef but if it weren't, it wouldn't be UnsupportedAnnotation necessarily either? Or am I barking up the wrong tree? 🌳

[eemeli]

If an implementation does define and support a private-use annotation, I think there are two options for its data model representation:

1. It's mapped to some representation within the base data model, e.g. as some func value or maybe as an operand of some sort. But then why need the new syntax in the first place?
2. The annotation is doing something truly different, and it doesn't fit within the base data model. In this case, the implementation extends the base, e.g. adding a new field in the Expression interfaces.

If going the first route, then interchange is of course easier, but that syntax will also have some representation without private use. If going the second route, interchange will require both ends to agree about the private-use.

[eemeli]

Dropped the matcher reserved-statement, as discussed in #548 (comment).