In the current development of the specification @ftc notice that different rules always share the same common subexpressions.
For example, the expression used to check if a view is attached is used in several rules and is, modulo the naming of the variables, used in different rules.
This makes writing and maintaining the rules time consuming and error prone (e.g. if a small bug is found in one of these common subexpression, all of them must be changed).
Also, having a "name" for these subexpression may be more convenient (i.e. the name abstracts the concept and the complexity of the subexpression).
A solution to improve the issue is to allow "named" regular expressions in the language.
For example:
We allow to parameterize the expression with free variables (hence, we cannot substitute the name of the method call). The substitution is by name.
When substituting all the variables that are not bounded (free) we substitute them with a free variable from the containing expression to avoid variable capture.
In the current development of the specification @ftc notice that different rules always share the same common subexpressions.
For example, the expression used to check if a view is attached is used in several rules and is, modulo the naming of the variables, used in different rules.
This makes writing and maintaining the rules time consuming and error prone (e.g. if a small bug is found in one of these common subexpression, all of them must be changed).
Also, having a "name" for these subexpression may be more convenient (i.e. the name abstracts the concept and the complexity of the subexpression).
A solution to improve the issue is to allow "named" regular expressions in the language. For example:
Then, the name can be used either inside another named expression or in a specification. For example: