rascal
rascal copied to clipboard
use of "uninitialized variable declarations" to declare type of free pattern variables
test bool matchSetExternalVar1() {set[int] S; return ({1, *S, 2} := {1,2,3} && S == {3});}
for example.
- It is useful to be able to declare the types of pattern variables ahead of the pattern, to keep the patterns readable and concise. Especially in concrete syntax patterns this matters.
- We might use the syntax:
Type Name;for this, but unitialized variables in Rascal in general are forbidden: there is no null at run-time and the checker should warn about any uninitialized variables - One way of solving the uninitialized variables issue is to remove the syntax
Type Name;from the language and only allowType Name = Expr;, but then we don't have a way to declare the types of free pattern variables anymore. - It would be an idea to have a different typepal role for pattern variables, say
freePatternVariable(), separate from normal variables. Pattern variables could be declared usingType Name;but they would be free, and can not be used outside of the scope where they are bound. - At the scope where pattern variables are bound, a new declaration of an
instantiatedPatternVariable()would be declared to shadow thefreePatternVariable()but inheriting the type of theinstantiatedPatternVariable. In this way no detailed flow analysis is required to satisfy the static checking requirements. Normal variables must be initialized and pattern variables must be bound. A rule must be added for any uses of freePatternVariables() other than in a pattern matching position, which is an error. - There is also a RAP for pattern variables to be final i.e. they can not be assigned into, and that would also require a different typepal role for these names.