World: r3wp

I wonder how much closures will be used. For some apps, probably 
a lot. But we do pretty well everything with FUNCs right now. Therefore 
I suggest CLOSURE to take three block arguments, as it will not be 
used as much in general.

(and if it does turn out to be used a lot, then that would justify 
adding a separate function, taking two blocks (probably called CLOS).

Common Lisp Object System? :-)

;-)

Closures: I never understood why we have FUNC and FUNCTION. I always 
use FUNC with /local, which seems very natural for me. So why not 
add something like: FUNC [a /static x /local b c d] ?

Than I see what every word is about. Otherwise I have to remember 
the semantics from the position of the blocks within a function definition.

Nice one! Ladislav, does it makes sense to add /static to FUNC, or 
does CLOSURE do something more?

Actually, CLOSURE does not have anything in common with STATIC, it 
is "more dynamic", than FUNC in a sense

(it looks like this confusion is my mistake - maybe I shouldn't have 
mentioned the STATIC variant?)

Why we have FUNC and FUNCTION: FUNCTION is older than FUNC, it is 
a "relic" from the Rebol1 days (some of my code survived the generation 
 change because I used FUNCTION)

the /static variant looks like unacceptable (incompatibility issues)

Anton: your argument looks to me as yet another reason why *not* 
have additional initialization block :-)

(in short I would "translate" it to: "I don't mind the bloat, because 
I am not going to use it as far as I know now")

As for my reply to closures, I am not that skilled to understand 
its immediate value - first example - what was difference to example 
using reduce? And couldn't the same be done with bind somehow? :-)

I feel that you are asking whether we can use closures in Rebol2 
version too. The answer is "yes", see my implementation of CLOSURE. 
OTOH, this should be implemented natively, because there will be 
a noticeable speed difference.

c: closure [/local a] [a: 0] [a: a + 1] ... so - do I understand 
it right, that we would have ability to e.g. set initial value for 
words which are local to functions? Currently it is not possible, 
is it? The only chance is to use 'a as a global word currently, no?

an example wich may show where initialization is useful, at least 
if i understand Carl correctly, is:

Both closure examples are actual console records from my computer 
in Rebol2 console using my (non-native) CLOSURE implementation

f: closure [/option val] [val: 1] [print val]

without the init block, you need to do:

f: closure [/option val] [val: any [val 1] print val]

the former would be faster. it's also more similar to other languages 
that offer optional arguments.

what is an /option, a refinement?

I do understand closure for ability to initialise local words, which 
we currently are not able, are we? I have a bit trouble with the 
name of the function though - "closure" - how do I translate it to 
myself? Is the name chosen because other languages use it too?

in your example, I don't recognise, if 'val is local, or global ....

the "CLOSURE" name is a bit unfortunate, the more appropriate name 
would be something like "PROPER-FUNC", because the goal is to have 
a more "expected" function behaviour

can't we just change current func? :-) Lot's of incompatibilities?

the problem is not with incompatibilities but with the speed, Carl 
is afraid, that the speed difference will be too big to get rid of 
FUNC

you know - above example gabriele posted, is not easy for newcomers 
and even for me. I sometimes miss, in rebol, to clearly SEE the scope 
of the word, its context ... is the value defined local, global, 
does function remember the state of locals or not, etc ....

but maybe it is just me and my lack of understanding ......

but - I can see some bugs with novices code - you define func, you 
think you are safe, as you think the word is always local as in most 
other languages and voila, then you wonder, what changed your value 
...

don't be afraid to see just the simple aspect there: as Gabriele 
is trying to point out, Carl probably meant a situation, where you 
can at the function definition time specify the initial values of 
optional (refinement - dependent) arguments

Currently all such function arguments are initialized to NONE

regarding variable "modification": in all cases the variables *are* 
local to the function, but (unfortunately) FUNCs "reuse" the variables, 
while CLOSUREs "create" new variables every time you call them

petr, does func [/optional val] [print val] seem confusing to you??

...that is why CLOSURES need to do more work and will be slower than 
FUNCs

G: no, it does not ... 1) it is just that from my english vocabulary 
I somehow miss relation to what actually "closure" word can point 
to in regards to programming language and functions in particular 
... 2) in regards to "confusion", the confusing part imo is, that 
one never know, how the function behaves - it needs studying ....

hmm, maybe all the trouble of novices - and I saw two of them doing 
the same "mistake" was, that they thought that words inside the function 
body are bound to function somehow locally ...

btw - are modules part of rebol 3.0? I am not sure, maybe a wrong 
idea, but with modules, you define 'export: [a b c] values, or import, 
or local and you have also 'options .... (and sorry if I got it wrong 
and if it would mean lots of incompatibilities), so, couldn't functions 
use similar technique? :-)

Petr, it doesn't help to know English. You still need to look up 
the programming meaning of "closure" to understand it.

Ladislav, my argument is not as you have summarized :-)  I mean, 
that I am happy with a "bloated" version named CLOSURE, because I 
know if we start to use it a lot and the bloat gets too annoying 
then we can always add CLOS.  Just like we got FUNCTION and then 
FUNC.  

I'm starting to think we can't avoid the extra block, anyway. It 
seems the nicest specification to me.

Pekr, the point is, that it's practically imopssible to catch all 
"vars" [*]to make them local, think about

	func [][do compose [(to set-word! "abc") 10]]


So it's better to have all "vars" defaulting to global. At least 
it's consistent that way (and faster).

[*] at least I guess it would mean a real big overhead.

Gabriele, that example is what was instinctively in my mind as the 
use case for initialization, but I couldn't describe it. I think 
initialization would be useful

Petr, my understanding of the English word closure as applied to 
an entity of code is that it is a closed compartment of both that 
piece of code and its variables with their values. If you move the 
piece of code around, those variables are still bound to it. The 
use for this is in fundamental things like multithreading and other 
async behavior, because it becomes easy to suspend a piece of high-level 
code and resume it later

may I add my grain of salt.  recently, I came about all of this issue 
in python.  and it was quite unexpected for me.

values defined as default arguments are just like /local variables 
in rebol, they are only defined once and persist from one function 
call to another.  thus blocks get re-used.  We get used to this in 
rebol and do our own copy []   and   return first reduce [val val:none]

values defined within the function body are always re-initialised... 
its much easier for python cause it uses dynamic scoping, instead 
of static binding.

why not, within the func dialect support:

func [val /option = 77] [print option]

when option is not specified, it is worth 77, when it is specified, 
it expects a value which is loaded within option.