red/help

For help with your code, suggestions and ideas, and learning Red.

Gregg Irwin

@greggirwin

One of the great and terrible things about Redbol langs is their chameleon ability. @nedzadarek, a great many details are hidden under a facade that makes Red quickly accessible to people, but there is the risk that they will see it "as just like X", when it really isn't.

Vladimir Vasilyev

@9214

>> 'x = red
== false

:^)

Gregg Irwin

@greggirwin

specialize: function [fun [function!] defs [block!]][
    spec: copy/deep spec-of :fun
    body: copy/deep body-of :fun

    foreach [arg value] defs [
        arg: to word! form arg
        pos: find spec arg
        remove/part pos pick [2 1] block? pos/2
        parse body rule: [some [change only arg value | into rule | skip]]
    ]
    func spec body
]

nedzadarek

@nedzadarek

@greggirwin yes, one thing I have found is that what you & 9214 talking about: scope of the function is non-existent

Vladimir Vasilyev

@9214

@greggirwin but you can't specialize curried function, because its arguments are not yet supplied.

Gregg Irwin

@greggirwin

>>     foo: func [x y][x + y]
== func [x y][x + y]
>>     
>>     bar: specialize :foo [x: 5]
== func [y][5 + y]

That's Doc's specialize func. As you can see, there is no outer scope for bar to see.

Maybe I don't understand the question then.

Vladimir Vasilyev

@9214

@greggirwin the goal is to turn

func [x y z][foo x bar y z]

into

func [x][func [y][func [z][foo x bar y z]]

Gregg Irwin

@greggirwin

@nedzadarek, and path! values are not OOP syntax.

Vladimir Vasilyev

@9214

so, e.g. func [y][...] should know in advance the value of x and capture it inside, in turn func [z][...] should know about x and y, otherwise inside its body x and y are unset.

nedzadarek

@nedzadarek

@greggirwin many OOP have syntax to access "subvalue", e.g. obj.foo. Similar syntax for accessing value from an array has C (arr[1]).

Vladimir Vasilyev

@9214

@nedzadarek it's not the same as paths, although they serve similar functions (indexing/accessing).

nedzadarek

@nedzadarek

That's what I mean. path!s are similar to OOP syntax.

Gregg Irwin

@greggirwin

@9214, I was looking for old examples, and this would maybe be good to add to the closure wiki page, because outer contexts are not available for uses cases like you describe. For that, we will probably use a closure mechanism.

nedzadarek

@nedzadarek

@9214 stupid idea: cant you just use stack/tree of contexts? So funA [funB [funC []]]: funA knows his own context, funB knows context of funA and his own context, funC knows context of: funA, funB and his own context.

Vladimir Vasilyev

@9214

@nedzadarek you'll need to extend such tree with new context each time the new argument is captured, too much overhead I guess.

Gregg Irwin

@greggirwin

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

nedzadarek

@nedzadarek

Of course you would have too keep it alive.

Vladimir Vasilyev

@9214

@greggirwin perhaps @nedzadarek meant explicitly creating object!s with set-word!s as arguments and their values, then rebinding body of the next function, then returning it.

hiiamboris

@hiiamboris

>> specialize func [x y z][g: does [print [x y z]] g] [x: 1]
== func [y z][g: does [print [1 y z]] g]

what's unset here?

Vladimir Vasilyev

@9214

@nedzadarek but you can't keep it alive, that's not the point of currying and partial application.

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.

nedzadarek

@nedzadarek

@9214 I mean funA has some context e.g. cA: context [x: 1] (so every x is bound to cA context). In funB you bind every x to cA and other variables to cB... and so on

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

@hiiamboris

>> specialize func [x y z][loop 5 [print x: x + 1]] [x: 1]
== func [y z][loop 5 [print 1 1 + 1]]

:D
why not just prepend x: 1 to the body of returned func and remove it from spec and close the case...

Vladimir Vasilyev

@9214

@nedzadarek yes, for that anonymous contexts or specializing proposed by @greggirwin is a way to go, I think.

nedzadarek

@nedzadarek

@9214 then I need to study it with fresh mind (sorry, it's night here)

Vladimir Vasilyev

@9214

@nedzadarek sure, it's night here too ;)

@hiiamboris except that your x is now leaking into global context

hiiamboris

@hiiamboris

hmm okay, add it to /locals then

nedzadarek

@nedzadarek

@hiiamboris other function can use x and every one would use different x(assuming /local x)

Vladimir Vasilyev

@9214

And it will last only for the next function, in the worst-case scenario you need to prepend x: 1 to each and every nested body.

And change /local part.

hiiamboris

@hiiamboris

=( I don't understand... can you make a quick example?

Vladimir Vasilyev

@9214

I don't understand it either, and it's 4:30 AM here.

nedzadarek

@nedzadarek

@9214 it's morning not night ;)

hiiamboris

@hiiamboris

oh I think I see what you mean, that next specialize invocation will have to read that x: 1 and append y: 2 to it

but it can read that, right? if it prepends it in the form set [vars] [values], this form stands

Vladimir Vasilyev

@9214

@hiiamboris kinda like that, yes, you then need to store/update those arg/value blocks somewhere, populate bodies on each invocation with them, and change /local ... in specs.

@nedzadarek night is in my mind. :zzz:

hiiamboris

@hiiamboris

can store them at the start of the body, why not?
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]]

Vladimir Vasilyev

@9214

@hiiamboris it's the other way around - you apply function to one argument and it returns you func [y][...] with other nested functions inside it.

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.

hiiamboris

@hiiamboris

what if specialize returned a wrapper to itself until there's no more arguments to apply?

Vladimir Vasilyev

@9214

I'd rather wrap myself in a blanket now.

hiiamboris

@hiiamboris

;)

Vladimir Vasilyev

@9214

http://www.sandipointe.com/im/pajamas/yummy-sushi-pajamas-9.gif

Where communities thrive

People

Repo info

Activity