ALF_ — Correction to Section 8.3.6, Property Access Expressions

There is a small problem in section 8.3.6 regarding property access expressions.
The problem is that the concrete syntax defined in that section will not
actually match the examples given in that section.

---------
Here is the concrete syntax defined in that section...

PropertyAccessExpression(e: PropertyAccessExpression)
= FeatureReference(e.featureReference)

FeatureReference(f: FeatureReference)
= FeatureTargetExpression(f.expression) "." NameBinding(f.nameBinding)

FeatureTargetExpression(e: Expression)
= NameTargetExpression(e)

NameTargetExpression(e: NameExpression)
= ColonQualifiedName(e.name)

Note that NameTargetExpression only allows ColonQualifiedName(s) to be used to
define a PropertyAccessExpression.

-------
Here are the examples of property access expressions from the same section...

poleValue.im
this.node
members.name
jack.house

Note that, because NameTargetExpression only allows ColonQualifiedName(s), none
of the above examples matches the concrete syntax.

----------
I suspect that NameTargetExpression should be defined to be a QualifiedName,
which is defined to be either a DotQualifiedName, an UnqualifiedName, or a
ColonQualifiedName, so...

NameTargetExpression(e: NameExpression)
= QualifiedName(e.name)

where QualifiedName is defined elsewhere as:

QualifiedName(q: QualifedName)
= ColonQualifiedName(q)

This is indeed a little confusing, but it is not actually an error in the spec. There is a note on page 38 that says:
“See Subclause 8.2 for rules on the disambiguation of a qualified name using the dot notation to a property access expression. Such a potentially ambiguous expression is always initially parsed as a qualified name.”
For example, as far as context-free parsing is concerned, an expression like “poleValue.im” is ambiguous – it could be a qualified name using the dot notation, or it could be a property access expression for the “im” attribute of the value of the name “poleValue”. Disambiguation requires using static semantic information on “poleValue” (e.g., is it a local name with a type that has an “im” property), as described in Subclause 8.2.
Despite this conceptual ambiguity, the formal grammar is made unambiguous by always parsing “poleValue.im” initially as a qualified name. That is why a dot qualified name is not allowed as a name target expression. Possible disambiguation to a property access expression then happens as part of static semantic analysis (this is formally through the derived QualifiedName::disambiguation attribute specified in Subclause 13.2.42).
Note also, by the way, that the grammar as given actually does parse “this.node” as a property access expression, because “this” is a reserved word, not a name. Thus, “this” is parsed as a NonNamePrimaryExpression (a ThisExpression, to be exact), not a NameTargetExpression.