Your closure environment consists entirely of comptime known constant values and not variables. That makes them plain old functions, not closures. This is a function generator pattern, not a closure pattern.
The usual definition of a closure (that you started your article with) is a function with bound free variables which implies some sort of additional state. Usually implemented as an additional environment pointer (often hidden by language syntax) which may vary at runtime.
A data analyst and developer utilizing Power BI, M Query, Access, Excel, VBA, MySQL, SQLite, SQL, JavaScript, TypeScript and dabbling in Zig for future projects.
The definition for ClosureBind is wrong, since it used comptime this: ClosureScope. The correct definition for ClosureBind should have omitted comptime, thus allowing free bound variables at runtme. I'll update the article. Thanks for the feedback.
Removing comptime from ClosureScope doesn't change anything. ClosureFunc returns a type and is therefore a comptime function and anything you pass to it has to be comptime known and is therefore implicitly also comptime. ClosureFunc is a comptime function generator that binds the function to some static values. It does not generate closures.
You can verify this in your example by passing a variable to TextInRange instead of a literal. Will get the message error: unable to resolve comptime value.
You can't implement closures without an additional state parameter at the closure call site. This is why closures in static languages are always some sort of object.
A data analyst and developer utilizing Power BI, M Query, Access, Excel, VBA, MySQL, SQLite, SQL, JavaScript, TypeScript and dabbling in Zig for future projects.
In response to your comment I added the following test which confirms your assertion that the presented implementation works only with compile time static values and my misunderstanding of Zig's comptime concept.
test"[Comptime Only Issue]"{// Test reuse invocation of the closure.varfrom:u32=undefined;varto:u32=undefined;from=2;to=5;constclosure=TextInRange(from,to);consttext=closure("0123456789");print("text = {s}\n",.{text});}
After further review of the presented implementation and a few minor changes to ClosureType and ClosureBind the above test passes using runtime variables. I'll update the article. Thanks for clarifying Zig's comptime concept.
For further actions, you may consider blocking this person and/or reporting abuse
These are not closures.
Your closure environment consists entirely of comptime known constant values and not variables. That makes them plain old functions, not closures. This is a function generator pattern, not a closure pattern.
The usual definition of a closure (that you started your article with) is a function with bound free variables which implies some sort of additional state. Usually implemented as an additional environment pointer (often hidden by language syntax) which may vary at runtime.
The definition for
ClosureBind
is wrong, since it usedcomptime this: ClosureScope
. The correct definition forClosureBind
should have omittedcomptime
, thus allowing free bound variables at runtme. I'll update the article. Thanks for the feedback.Removing comptime from
ClosureScope
doesn't change anything.ClosureFunc
returns a type and is therefore a comptime function and anything you pass to it has to be comptime known and is therefore implicitly also comptime.ClosureFunc
is a comptime function generator that binds the function to some static values. It does not generate closures.You can verify this in your example by passing a variable to
TextInRange
instead of a literal. Will get the messageerror: unable to resolve comptime value
.You can't implement closures without an additional state parameter at the closure call site. This is why closures in static languages are always some sort of object.
In response to your comment I added the following test which confirms your assertion that the presented implementation works only with compile time static values and my misunderstanding of Zig's
comptime
concept.After further review of the presented implementation and a few minor changes to
ClosureType
andClosureBind
the above test passes using runtime variables. I'll update the article. Thanks for clarifying Zig'scomptime
concept.