You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We copied the idea of treating [][] in a sense as a single operator. For example in the expression v[i][j]. This was copied from the reference parser. The reference parser in turn seems to be influenced by the way composition of indexing is presented in the spec.
However, I think this is a clumsy and complex approach. I am unaware of any language that treats v[i][j] differently than (v[i])[j]).
We should re-implement this in the standard way. I could list reasons, but I don't know who I'm trying to convince.
The complexity of [][] is currently handled everywhere by code to check how many indexing ops are present and to organize them in an array. Or organize them by marking a stream with tags as in the green tree, etc. If this is instead treated as two separate indexing operations, then all complexity is handled by the generic machinery for handling expression trees, with no special provisions.
The same argument above applies to all analysis, such as semantic analysis. There is generic machinery for analyzing nested expressions. As it is, we have to implement some parallel machinery just to handle repeated indexing.
The text was updated successfully, but these errors were encountered:
We copied the idea of treating
[][]
in a sense as a single operator. For example in the expressionv[i][j]
. This was copied from the reference parser. The reference parser in turn seems to be influenced by the way composition of indexing is presented in the spec.However, I think this is a clumsy and complex approach. I am unaware of any language that treats
v[i][j]
differently than(v[i])[j])
.We should re-implement this in the standard way. I could list reasons, but I don't know who I'm trying to convince.
[][]
is currently handled everywhere by code to check how many indexing ops are present and to organize them in an array. Or organize them by marking a stream with tags as in the green tree, etc. If this is instead treated as two separate indexing operations, then all complexity is handled by the generic machinery for handling expression trees, with no special provisions.The text was updated successfully, but these errors were encountered: