I’ve had an epiphany about our grammar.
We have a few grammatical concepts that serve multiple purposes, and thus the grammar productions have possibly-conflicting purposes. There’s also two different perspectives on each. One is what I’ll call value space, the other I’ll call accessor space
Value space
VariantList
VariantList is used in Terms and SelectExpressions.
By the use in Terms, VariantKey is the value space of grammatical concepts like declension. Nominativ, Akkusativ, Singular, Plural. These concepts can be nested.
By the use in SelectExpressions, VariantKey is the value space of InlineExpression, plus explicit numbers. Inline expressions can be external variable references, so anything a program can pass in. They can also be the result of call expressions, so the value space of global functions. Examples would be platform globals. And they can be Term attribute references, which links back to grammatical concepts, like männlich, weiblich.
SelectExpressions can be nested, and there’s an open issue on adding a flattened multi-selector.
Attribute
Attributes are used for DOM node attribute localization on Messages, and for linguistic metadata on Terms.
DOM node attribute names have their value space defined in the XML spec.
Terms have their names and values of Attributes given by grammatical concepts, names being Geschlecht, for example, and values being männlich, weiblich.
One part of the story is how to express programmatic and linguistic concepts in Fluent. The other part is how to reference these, and make decisions upon.
Accessor space
The accessor space is given by AttributeExpression and VariantExpression. Attributes are referenced by ., and Variants by []
In the accessor space, it’s becoming interesting how we allow to nest things. If you can nest Attributes in Attributes, you need to remove the . from the attribute accessor space. If you can nest VariantLists in Attributes, you need to remove at least [. We also need to handle space as an outside separator of the accessor space.
If one of our value spaces needs characters that can’t be in our accessor space, we’ll need to break out of the accessor space, by an escape or so.
Open Questions
- Does that sermon make sense?
- Do we want Attributes on Attributes?
- Do we want VariantLists on Attributes? That question only applies to Terms, right?
- Do we want Attributes on VariantLists?
- Do we want VariantLists on VariantLists? (We do now, putting here for posterity)
- … as a follow-up, we have two proposals for SelectorLists,
[foo,bar]and[foo][bar]