rascal icon indicating copy to clipboard operation
rascal copied to clipboard

use of "uninitialized variable declarations" to declare type of free pattern variables

Open jurgenvinju opened this issue 5 years ago • 0 comments

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 allow Type 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 using Type 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 the freePatternVariable() but inheriting the type of the instantiatedPatternVariable. 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.

jurgenvinju avatar Feb 12 '20 09:02 jurgenvinju