Currently exprFVs and compFVs don't find the free variables in types. Depending on how they are used, this may or may not be a problem. For example, exprFVs is used to find the free variables in a local function definition, because when we generate code local functions become global C functions and the their free variables become additional parameters. Consider something like
fun comp f(arr[_r] int x) {
fun comp g() {
var y : arr[_r];
..
}
..
}
in this case _r is a free variable inside the nested function g, albeit in a type -- but it nevertheless should become an additional argument to the code generated for g.
Incidentally, tests/backend/perm_test.wpl, wit an addiitonal printlninserted before the var in function perm goes wrong for precisely these sorts of reasons: function inlining is not inlining inside types.
Currently
exprFVs
andcompFVs
don't find the free variables in types. Depending on how they are used, this may or may not be a problem. For example,exprFVs
is used to find the free variables in a local function definition, because when we generate code local functions become global C functions and the their free variables become additional parameters. Consider something likein this case
_r
is a free variable inside the nested functiong
, albeit in a type -- but it nevertheless should become an additional argument to the code generated forg
.Incidentally,
tests/backend/perm_test.wpl
, wit an addiitonalprintln
inserted before thevar
in functionperm
goes wrong for precisely these sorts of reasons: function inlining is not inlining inside types.