Disallow subsumption in qualified variable names

[JimLarson]

Change

I'm not a fan of qualified (dotted) variable names, largely because they effectively change the AST at eval-time. For instance, the expression a.b.c parses to the AST

select(select(ident("a"), "b"), "c")

but at eval-time it might also be interpreted as

select(ident("a.b"), "c")

or

ident("a.b.c")

depending on whether bindings are given for a, a.b, or a.b.c, respectively. Complicated disambiguation rules are given in case several of these bindings are present at once. The implementation must either rewrite the AST in a pre-pass at evaluation time, or perform the equivalent re-interpretation on-the-fly, at the cost of complexity.

A potentially simpler semantics is to work "as if" providing a qualified name binding a.b.c implicitly creates only a binding a as a map with field "b", which itself is a map with field "c". If several qualified bindings are present with similar prefixes, they share the implicitly-constructed maps. This allows the AST to retain its original interpretation.

Before anyone objects to the performance of this, the key here is the clause "as if". The implementation is free analyze the expression to fast-path the access to nested maps - but now this optimization can apply to all maps, not just those implicitly constructed from qualified bindings.

TBD: analyze the interaction with non-empty containers.

But this interpretation / implementation forbids one thing: having a as both an explicit binding and an implicitly-constructed binding. I.e. if you provide a binding for a.b.c, it is illegal to also provide bindings for a or a.b.

So the request here is to disallow such "subsumed" bindings when qualified identifiers are bound.

Example

Examples given above. Contrast the current complexity of name resolution.

Alternatives considered

I wouldn't object if qualified identifiers went away entirely, but I hear that there is some demand for them.

[JimLarson]

In addition to disallowing a and a.b as bindings, they'd also be disallowed as variables used in the expression - you're not allowed to rely on the implicit maps actually getting built.

[JimLarson]

Another point in favor of disallowing subsumption: the language spec states that we can force interpretation of a.b.c as (a.b).c by using explicit parentheses. But this is not correct: the parens are lost after parsing so these look the same in the AST. This leaves us with no way to distinguish the two. But the problem only arises because a.b is subsumed by a.b.c. If subsumption is prohibited, there is no ambiguity.