World: r3wp

My idea is, if a function has lots of constants, programmers may 
just put them in an object?

So the function doesn't have to initialize them every time.

Geomol: my guess is, that if you wrote: context [a: 1 / 2 / pi set 
'f closure [x] [a * sine/radians x]], you wouldn't be slower than 
the initialization block can be while retaining the "static nature" 
of the defined variables, that can be even changed when wanted

Isn't the conclusion then, that closure doesn't need the extra block? 
It's possible to have the speed without, and the extra block will 
complicate the syntax.

I gotta sleep too. Working day tomorrow.

good night to you and everybody

night!

I think not having the extra block is better, and concise.

which orca-site? trac (but timeline says nothing), campfire or altme?

sorry, wrong group..

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.