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.
https://github.com/red/red/wiki/Guru-Meditations#function-contexts
Or first specialize it and substitute each occurrence of the new argument by its value, then return.
Though I'm not sure how viable it is.
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.
@hiiamboris except that your
x is now leaking into global context
And change
/local part.
but it can read that, right? if it prepends it in the form
set [vars] [values], this form stands
@nedzadarek night is in my mind. :zzz:
can store them at the start of the body, why not?
x=1 =>
y=2 =>
z=3 =>
func [x y z][loop 5 [print x: x + 1]]x=1 =>
func [y z /local x][set [x][1] loop 5 [print [x: x + 1]]y=2 =>
func [z /local x y][set [x y][1 2] loop 5 [print [x: x + 1]]z=3 =>
func [/local x y z][set [x y z][1 2 3] loop 5 [print [x: x + 1]]
But
x value should be preserved somehow, so that those nested functions are able to access it. Same with other arguments.
And this is what closure does - it references a variable in the scope where it was defined.
Localization is an interesting approach, I didn't think about that much.
to clarify the point above:
so you only have to call spec() once on a normal function to construct a currying variant, and then each call just adds an argument until there's only one argument remains and the function itself is returned
it's all great in theory though, but in practice a returned function will be just data (it won't accept arguments yet), so you'll need an operator (or
spec(x0,f(x,y,z)) when called returns spec(y0,f(y,z,x=x0)), and the new one => f(z,x=x0,y=y0)so you only have to call spec() once on a normal function to construct a currying variant, and then each call just adds an argument until there's only one argument remains and the function itself is returned
it's all great in theory though, but in practice a returned function will be just data (it won't accept arguments yet), so you'll need an operator (or
do reduce [..]) to call it
@hiiamboris
in requires a stack slot copy while bind just 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.
@hiiamboris my answer would the basic version of @dockimbel's -
bind modifies context pointer in slot and returns it, while in allocates an extra copy, so as to avoid modification of the original word (I guess?).
I feel frustrated: why this basic switch doesn't work :smile:
type: word!;
probe type? type ; datatype!
probe type? word! ; datatype!
probe (type = word!); true
switch type [
unset! [
print "unset!"
]
word! string! file! url! block! [
print "word! string! file! url! block!"
]
]