World: r3wp

Is it possible to bind a function's body to a new context in R3? 
In R2, it can be done with

	bind second :f new-context

Yes

As follows:

    f: make function! reduce [spec body]
    bind body new-context

How?

ok

So, I suppose it is a safety measure: without having the function 
body available, you cannot do it.

I get some errors (under OS X):

>> bind 'body o
** Script error: body is not in the specified context
>> bind [body] o 
== [body]
>> f 1
** Script error: a has no value

My f, body and o are defined this way:

>> f: func [v] body: [v + a] 
>> o: context [a: 1]

Hm, I did it wrong, I think, but still doesn't work with:

	bind body o

Still wrong

:) I need a language without BIND!

>> f: make function! reduce [[v] body: [v + a]]
>> o: context [a: 1]
== make object! [
    a: 1
]

>> bind body o
== [v + a]

Isn't that the same as my last attemp?

NO

:) Need to think.

you *have to* use MAKE FUNCTION!

Because FUNC do copy/deep. hmm is this smart?

yes

you are protected when using FUNC, while you are allowed to do what 
you want when knowing what you are doing

What if ... this is radical, but try go with me ... what if block's 
content wasn't bound to any context, when the block is made? And 
then the content is just bound to a context, when and if the block 
is being evaluated (or compiled if a language does that) the first 
time. Doing it this way, words are treated just like any other value 
within the block. They don't hold any other meaning than the words 
themselves. What would the consequences be?

The same could be done with functions, as the function body is just 
a block of data, which may or may not be evaluated (or compiled).

What would the consequences be?

 - I do not know, you did not give me enough specifications to be 
 able to guess.

But, my guess is, that if done carefully, such a "change" would be 
indiscernible from the current behaviour.

An example:

blk: [a + b]
f: func [blk /local a b] [a: 1 b: 2 do blk]
f blk

If this would work, what other consequences would that have?

Geomol, you want Scheme.

Gab, doesn't Scheme have such syntax, we don't like?

Seem to have all the paranthesis, Lisp have.

This needs some thought, Geomol. Actual example:

f1: closure [/local a][a: 1 [a]]
f2: func [blk /local a][a: 2 do blk]
f3: func [blk /local a][a: 3 do bind blk 'a]

>> f2 f1
== 1

>> f3 f1
== 3

Now tell us, how your preferred code achieving the same result should 
look like.

I wouldn't have closure, but use object instead (or context, as I 
call them), if that functionality is wanted. And block content isn't 
bound to start with, so if I write:

>> f1: [a]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 2


because 'a' inside f1 is bound to local 'a' in f2, when evaluated. 
If I want another 'a', I could write:


>> context [a: 1 set 'f1 compile [a]]	; f1 will be a block, [a], 
where the 'a' is bound to 'a' in the context
>> f2 f1
== 1

and the last result could be achieved:

>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


Calling f3 will be slower, as blk is recompiled each time. This language, 
I illustrate, isn't REBOL, but another with many similarities to 
REBOL, but with a compile function. Maybe kinda the same could be 
achieved in REBOL, if the binding rules was changed, and "compile" 
in my examples above was changed to a "rebind" function.

I need to think it through, if other unwanted consequences is the 
result of this. I'm just wondering, why it's designed as it is in 
REBOL.

I wouldn't have closure

 do I understand correctly, that you do want the programmers to enjoy 
 the benefits of having closures?

err, "do not want" is what I wanted to write

Well, if function variables is needed, after the function is finished, 
then it can be achieved by putting the function in a context, and 
have the local vars be vars in the context instead. It's simpler, 
I think, to program.

It is not simpler, you just are forbidding a useful feature.

I guess, the closure functionality could be achieved by a mezzanine 
and using object! and function! datatypes without having closure! 
datatype. I'm not an expert in closures, so I may be wrong. Are there 
more to them?

So, if you would not forbid the CLOSURE to be implemented as a mezzanine, 
my question remains valid.

Is a closure a function, where the vars is in a map (or whatever 
data structure is used for an object/context) instead of on the stack?

You can have a look at

    source closure

in 2.7.7 or above

I wouldn't and couldn't forbid closures, if they could be implemented 
using function! and object!, even if the language didn't have closure! 
.

In that case, as already mentioned, my example remains valid, and 
the question is, how would you want to implement that functionality.

(the above implementation does not use the object! datatype)

I just noticed. Interesting! :) I need to read the source to "closure" 
closely.

Do you follow my ideas for blocks without default binding? I think, 
it could work.

So, my question was, how would you implement F1, F2 and F3 in your 
hypothetical language to get:

>> f2 f1
== 1

>> f3 f1
== 3

It is not simpler, you just are forbidding a useful feature.


If closure! could be avoided, then the C source for the language 
is simpler. That's what I mean. If the closure functionality can 
be achieved by a mezzanine, nothing has been forbidden. Of course, 
if the language doesn't have problems with keeping the C source simple, 
a closure! datatype could be included, as it would possible be faster.

I already gave examples to do that. They were:

>> context [a: 1 set 'f1 compile [a]]
>> f2: func [blk /local a] [a: 2 do blk]
>> f2 f1
== 1
>> f3: func [blk /local a] [a: 3 do compile blk]
>> f3 f1
== 3


I haven't finished reading about CLOSURE, so maybe it can be even 
simpler.

Isn't it correct, that the CLOSURE mezzanine in R2 only work (without 
using object! in any way), because functions are already closures 
in R2?

Nope.

Yeah, it is. Else the CLOSURE mezzanine would work in R3 with R3's 
functions, and it doesn't.

Why does R2's CLOSURE parse of set-word! in the spec? Doesn't make 
sense.