World: r3wp

How would a function be defined with the same functionality as your 
lfunc?

it is quite easy to define as a mezzanine, you may either have a 
look at the implementation mentioned above or ask me to post somewhere 
a simplified version (because the one mentioned above is probably 
more complicated than you would like...). Disadvantages of my LFUNC 
are, that it needs one special "static" context created when the 
function is being defined, which costs some time, e.g.

So your lfunc will still work in REBOL3, as it does now?

I am pretty sure it will, at worst with a simple modification

To understand it better...
I can make a function this way to have initialisation every time:
f: func [/local a] [a: 0 a: a + 1]

What exactly is the goal with CLOSURE?

example of the CLOSURE behaviour:

b: []
    f: closure [x] [append b 'x]
    f 1 ; == [x]
    f 2 ; == [x x]
    reduce b ; == [1 2]

; which means, closure variables somehow "remember" their values, 
compare it to:

>> g: func [x] [append a 'x]
>> g 1
== [x]
>> g 2
== [x x]
>> reduce a
== [2 2]

(where a was defined to be an empty block initially)

hm tricky. It needs some getting used to. And you question is, if 
closure should initialise very time? What will happen, if it doesn't?

CLOSURES are actually something like "more proper" functions, but 
their evaluation is "more expensive" (takes more time)

Will people understand the difference?

And is it usefull?

will people understand the difference: *if* they come into trouble 
when using FUNCS, closures may help them to obtain the desired behaviour

more "persuasive" example:

ahh, good point!

make-f-returning: func [x] [does [x]]
f-returning-ok: make-f-returning "ok"
f-returning-ok ; == "ok"
f-returning-wrong: make-f-returning "wrong"
f-returning-wrong ; == "wrong"
f-returning-ok ; == "wrong"

make-g-returning: closure [x] [does [x]]
g-returning-ok: make-g-returning "ok"
g-returning-ok ; == "ok"
g-returning-wrong: make-g-returning "wrong"
g-returning-wrong ; == "wrong"
g-returning-ok ; == "ok"

what do you say to this?

the alternative to the initialization block is to not use it and 
initialize everything to NONE like in the FUNC case

ok, I see the difference. And I guess, it's benefitial, because using 
bind can be difficult.

And your question is, if closure should have a third block with "cheap" 
initializations?

Like in your:
 c: closure [/local a] [a: 0] [a: a + 1]

the question is, if users want to have the additional (actually second) 
block for the initialization purposes of do not mind to have everything 
initialized to NONE

Damn hard question! :-)

It mayl be easier to say, when I've done 10 programs using closure. 
But I'll think about it.

may

you do not have to know anything about closure, you may imagine the 
same question for FUNC case: would you appreciate to be able to specify 
the initial values for locals?

Before I answer that..

I use FUNC all the time. I almost never use FUNCTION. I guess, because 
I have to write more with FUNCTION.
I also started to use HAS and DOES, when I found those.

CLOSURE may come in the group with FUNCTION, if it get 3 blocks as 
arguments, so I may not use it.

Could it be possible to make the initial assignments in the first 
(and only) argument block?

the only disadvantage of initialization I came to is the more complicated 
interface to CLOSURE needing always one more block to specify

I think, that's a very good point! REBOL programmers don't like to 
write much.

it may be possible to put the initializations into the first block 
but that would cost some syntax complications and differencess too...

yeah

Could we have 2 versions of closure, like we have func and function? 
One where init = NONE and one with the extra block?

probably yes, although Carl always hesitates to include unwanted 
features

I can understand that.

Let's see another example with the extra block:
f: closure [x /local a]Ê[a: 2 * pi] [(sine/radians x) / a]

without:
f: closure [x /local a] [a: 2 * pi (sine/radians x) / a]


Is it something like this, you're thinking about? And will the first 
be faster than the second?

And the third possibility (which maybe not is very REBOLish):
f: closure [x /local a: 2 * pi] [(sine/radians x) / a]

Ladislav, will rebcode be part of REBOL3? Do you know?

I do not know, but think so

Is the idea, that the second closure block will only be parsed one 
time? (and therefore be fast)

yes

Rebcode is mentioned on the roadmap doc

Ok, functions with many constants will be much faster with this extra 
block then, right?

faster, yes, much faster - maybe not

Where is your opinion against? With or without the extra block?

my opinion is not strong, therefore I am asking

hehe :)