Function contexts only exist while they are being evaluated. In this example, you are not evaluating the inner funcs while the outer func is active.
but you can't keep it alive, that's not the point of currying and partial application.
but you have to keep variables alive, right? So, for example you have too keep
x till no other inner function use it.
xis now leaking into global context
set [vars] [values], this form stands
func [x y z][loop 5 [print x: x + 1]]
func [y z /local x][set [x] loop 5 [print [x: x + 1]]
func [z /local x y][set [x y][1 2] loop 5 [print [x: x + 1]]
func [/local x y z][set [x y z][1 2 3] loop 5 [print [x: x + 1]]
xvalue should be preserved somehow, so that those nested functions are able to access it. Same with other arguments.
spec(x0,f(x,y,z))when called returns
spec(y0,f(y,z,x=x0)), and the new one =>
do reduce [..]) to call it
inrequires a stack slot copy while
bindjust modifies the first argument slot on stack, and re-use it as returned value. The incurred overhead exists because such copy boils down to an expensive
memcpy(), which could be replaced in a future (once we start working on optimizations) by a simple read/write using an SSE 128-bit wide register. Once such optimization is done, the difference should become insignificant.
bindmodifies context pointer in slot and returns it, while
inallocates an extra copy, so as to avoid modification of the original word (I guess?).