Often when navigating deeply nested hierarchies, it is not clear what is the target a parent expression is referring to. For example,
abstract A -> integer
abstract B -> integer
abstract C
abstract D
c -> C
[ this.c.dref.parent.parent.dref ]
Instead, we could write the constraint a bit differently using the "self-explanatory parent":
[ this.c.dref.^B.^A.dref ]
which can be read "go through the reference c to a C, then to its parent B, then to its parent A, and through the reference". For now, the statement in this notation would simply desugar to the original expression; however, additional checks are now possible (whether the resulting target of the parent is indeed what the user intended).
Solution. For now, the syntax ^<id> should simply desugar to parent. Later, we should have a new IR element and use the identifier <id> during type checking.
Often when navigating deeply nested hierarchies, it is not clear what is the target a
parent
expression is referring to. For example,Instead, we could write the constraint a bit differently using the "self-explanatory parent":
which can be read "go through the reference c to a C, then to its parent B, then to its parent A, and through the reference". For now, the statement in this notation would simply desugar to the original expression; however, additional checks are now possible (whether the resulting target of the
parent
is indeed what the user intended).