This is not a correct fix, better remove it.

Capturing a context of variables would require to collect all the context at the time a function call is captured (e.g like the filter) and to reintroduce this context when it is evaluated.

Here you are using the current context, not the one that should have been captured by the function call.

As I said, doing a proper capture is way more involving, and I would prefer that we don't handle that for now because it is complicated to get it right.

To illustrate the issue, imagine that you have something like that:

func f(x); for y in [1..10]; ret [1,2,3] | array.each @(do; ret x + y; end;); end; end;
z = f(1)
for w in z
  w
end

when evaluating z in the following for, the function @(do; ret x + y; end;); will be indirectly called. But the context of x and y will have been lost. In order to support that, Scriban would have to capture entirely the context of evaluation of variables (coming from the for loop inside the f(x) function, + the f(x) function itself). Doing this is quite challenging and I didn't introduce it in Scriban in the 1st place for this reason.

Without this change, it's still possible to capture a loop variable like this (assignment to a temporary variable)..

for a in [1]
b=a
fn =@(do; ret b ;end}
ret fn
end

which is good enough for the scenarios I care about.

Oh, ok, but it would introduce non wanted behavior, because here you start to look back to contextStack, meaning that you would start to access the for loop also of a calling function, for which a capture should not be supported.

e.g:

func f(x); for y in x; ret g(y); end; end;
func g(w); for z in x; ret y; end; end;

With your change, I would think that ret y would be able to access the context of the calling loop y, which wouldn't be what we want.

I don't think it can be solved like that. Scriban doesn't support the concept of closure and capture variables. It requires a different way to resolve variable, which is beyond the scope of this fix for now.

To illustrate the issue, imagine that you have something like that:

Yes agreed, this is considerably more complicated than can be handled by the changes I have made. The motivation for these changes is to support this kind of thing:

{{
#library code

func take(a,b)
 if (string.contains a b)
   ret a
 else 
   ret null
 end
end

func takeLines(lines,text)
  ret array.filter lines @(do;ret take($0,text);end))
end
}}

{{
#user code - having defined the functions the syntax for filtering lines is now quite clean....
model = ["log line","sensor a","another log line"]
lines =model  |  takeLines  "sensors" 
}}

Without being able to capture any variables, the only way to implement "takeLines" appears to be to use text evaluation...

{{func takeLines(lines,text)
str = "{{f=  @(do;ret take($0,\"" + text +"\");end)}}"
object.eval_template str
ret (array.filter lines @f)
end}}

or perhaps to give up the array iterators completely and just use for loops...

I understand if you don't want a "partial" fix but as you say a full one really requires a fundamentally different approach. I'll back out the TemplateContext.Variable change and associated tests in any case.

Should not be changed I think