World: r3wp

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.

we don't use a second word, to simplify syntax, and cause in this 
context, we expect option not as a conditional argument, but as a 
something which always has a value.  the current refinement syntax 
still stays intact and this is easy to read and understand.

maybe 2 cent of mine:

to me it looks pretty confusing, reading all the above - if I get 
the intention right I would separate it like this

1) how to (or do we want) initialization - no matter if with closures 
or just normal rebol funcs

2) how will closures be in rebol3, by default (breaks a lot as Ladislav 
told) or not
3) the static thing Ladislav began with

@ 1) 

- to me this doesn't belong to the whole closure discussion (if it 
deeply does I don't get right now why) 

- one possibility would be to add an refinement to func or closure 
also - no? - makes the order of the optional third block a bit awkward, 
but on the other side that's what refinements are for - no ?

@ 2)

- we should have closures and propagate them as the default version 
for normal people or newcomers if rebol3 is out - they are safer 
IMO and don't make too much trouble with unexpected effects, especially 
for people from other languages (especially from the current dynamic 
kind)
- so closure should be separate

- with hopefully more asynch behavior by default build in, in rebol3, 
closures are anyway a must 

- if somebody got the concept of normal funcs - people can use it 
for speed reasons easily

- from Gabriele or Ladislav (or somebody else) it sounded a bit like 
one of the thoughts around closures involved the binding capabilities 
- I don't overlook this right now, but it still would be possible 
to change funcs like today, wouldn't it ? I mean there might be something 
like changing a function or rebinding it's body (or parts of it) 
can cause problems if local vars of a closure should be protected 
by this - on the other side who would do this, who doesn't know what 
he does ?


@ 3) maybe some of the static capabilities would be nice to have 
for closures then too, don't know - right now it's easy to build 
- how would it be done (in the language) with closures ?

And just some questions:

what function attributes will be added ? and what will they do, what 
purpose for .... :-)

will they be kind of dynamic or user extendable - so that own attributes 
could be defined - even if not too useful with rebol in some sense 
(or maybe it is - i'm not sure) - so some design by contract could 
be added without hacks for some needs (just mean it as an example)

will function get more similar to objects/contexts (or the other 
way around) - I mean that the concepts get closer ?

Maxim, I'm a little unclear about that. Does it mean:
f: func [val /option = 77][print option]
f 123 
; ==> 77
f/option 123 88
; ==> 88


So is it that just the presence of the equal sign '= after a refinement 
in the func spec block creates the closure instead of a normal function 
?

anton, yep.  but we still support the old methods too, dialect wise 
there is not collision :-)

IMHO its pretty obvious even for the newbie... heck I tried that 
years ago and was disapointed it didn't work...

IMHO, more importantly this should happen when used with series: 

f: func [/blk = [] ] [append blk "a" probe blk]
f
==> ["a"]
f
==> ["a"]

NOT:
 
f: func [/blk = [] ] [append blk "a" probe blk]
f
==> ["a"]
f
==> ["a" "a"]

and in such a case, the func must release any reference to blk or 
else the GC cannot clean it up.

maybe a new parameter  ( /clean /free /trash ?) to allow /local words 
to be reset on entry AND/OR exit would be cool, to help with memory 
leaks, especially on loops , recursive code, and contexts... a lot 
of ram can be locked, just cause there is a reference to data within 
a function body local word.

i think it should be made clear that initialization is not a property 
of closures, it's just that it comes free with closures because a 
new context needs to be created each time anyway. so, since it comes 
free, should we expose that as an argument to CLOSURE?