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
TutorialD (master/main): x:=with (x as true) x
("with type",Relation (attributesFromList []) (RelationTupleSet {asList = []}))
("with type",Relation (attributesFromList []) (RelationTupleSet {asList = []}))
TutorialD (master/main): :showexpr x
ERR: RelVarAlreadyDefinedError "x"
The original expression should almost certainly be rejected, but the relational expression validation is sound, so we would need to check that the new relvarname "x" is not mentioned in the with clause names.
I am toying with the idea of preventing name shadowing of relvars or other with clause macro names (even macros shadowing macros). It does seem that name shadowing can be sometimes useful when moving subexpressions around, but the risk and cost of mistakes here is very high.
Any objection?
The text was updated successfully, but these errors were encountered:
Indeed, it's just on a future branch, but what's the point of supporting that expression? It makes substitution much more difficult and optimizations have to track shadowed names recursively.
Name shadowing can be quite a footgun. Example:
The original expression should almost certainly be rejected, but the relational expression validation is sound, so we would need to check that the new relvarname "x" is not mentioned in the with clause names.
I am toying with the idea of preventing name shadowing of relvars or other with clause macro names (even macros shadowing macros). It does seem that name shadowing can be sometimes useful when moving subexpressions around, but the risk and cost of mistakes here is very high.
Any objection?
The text was updated successfully, but these errors were encountered: