World: r3wp

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?

this was a clear question imo :-)

everything else is unrelated. making closure the default would probably 
be a performance hit, and most people wouldn't really notice the 
difference (newbies don't expect closures, unless they come from 
lisp)

Kind of what I was thinking. At the base level, for most users, it 
would be very nice to have default values, but not many folks will 
even know what closures *are*.

but I think they don't expect some of the side-effects which wouldn't 
be there with closures - at least I thought this until now

closure does not remove the side effects

I don't like the extra block syntax, as that seems clunky. I don't 
care for Max's = syntax, because the = is just non-REBOlish in the 
context of setting a value.

closure allows you to do things that you can't do with funcs

I'd prefer /option: 6

I mean the examples from Ladislav when you use some of the capabilities 
of Rebol and get hit by not copying the context

but is that possible in rebol?

I think we need an extended func dialect.

that's exactly what I mean.

Yes, max, it is.

max, refinements are logic (none or true), they don't get a value

what about using a refinement in general for a optional intialization 
block ?

Yes, I'm in agreement with you here Max, just not the = syntax.

and depending on the needs of the func spec, it switched to closure

so you'd have /option val: 77, but this is a potential problem with 
return: in routines for e.g.

Michael, I don't know if that's any better than an extra block, because 
you have to redundantly name the values.

why use two words.

because you have refinements without args, with one arg, with two... 
and so on

I think default values need to be specifiable like help strings are, 
but I haven't thought about the specific syntax yet.

/option, /option val, /option val1 val2

what I think is that not everybody wants it (because could be optional) 
and a refinement would add it if wanted

but the word is ALWAYS set, so in the context of its useage, its 
not optional.

I know there are drawbacks, but why not 
f: func/init [arg] [print arg] [arg: 2]
and
f: func [arg][print arg]

cause the init block can be 2 pages further down the editor?  ;-)

this breaks no code and uses the existing facilities 

yes that's the drawback

I thought of that too, and came up with the same problem Max did. 
:-\

why not:

 f: func/init [arg] [[arg: 2]  print arg]