World: r4wp

Nobody will use functions anymore after that demonstration Ladislav!

:-D

I should check whether closures are implemented optimally, having 
the source code available.

Hmm, I thought that's what funct is for, but apparently I was wrong 
- funct just seems to make all set-words local, but not passed in 
arguments ...

well, this is something else than what FUNCT does. Making some variables 
local can be useful for closures as well.

Great works Ladislav, added to http://rebol.informe.com/wiki/view/Rebol_3-closure
 wiki

MaxV: one more improvement to the text; I wrote:

c: closure [a [number!]] [func [b [number!]] [a + b]]

, but, actually, I think that

c: closure [a [number!]] [closure [b [number!]] [a + b]]

wold look better (more uniform)

What I am still afraid of is the fact that the "Closure" name could 
scare beginners looking sufficiently "unfamiliar" and "exotic", while 
I think that what *should* scare beginners as far as the behaviour 
is observed is actually "Function".

When all these renaming issues are discussed I think that it might 
make sense to think about the name in this context as well.

I agree that the name "closure" is not user-friendly. Also, I wonder 
if it shouldn't be the default function constructor (also thinking 
loud for Red). I'm still unsure about that though.

Certainly the series copy trap is the one beginners will fall into 
most. Higher order functions won't be in their code, probably until 
they are comfortable with 'closure.

...but the GUI example should be in the repertoire of beginners, 
don't you think? (and it even "caught" Cyphre, so he asked me how 
to do it properly using function, so I had to tell him: "don't")

Agreed with both of you on naming. Now is the time to consider what 
to change in R3 and what to use in Red. 'Closure has meaning beyond 
Ladislav's current examples. Do we name things for new users and 
novices, or experts? For me, name things clearly, and supplement 
with docs if the names don't match expectation.

On the GUI, yes, perhaps.

The "series copy trap" is what makes me hesitate about making closures 
the default function constructor. I think it should not be a "trap" 
in the first place, it is just undocumented, while it should IMHO 
be very clearly explained in the series chapter. Understanding how 
literal series behave is an important step in understanding Rebol.

Doc +1

In this case "function" obviously does not match expectation, while 
"closure" matches expectation for "function", otherwise looking too 
"scary" to provoke some of its own.

Yes. The question for me is why function doesn't work, since I haven't 
done any R3 GUIs yet.

That is, do we address it in the implementation or naming (e.g. alias 
closure as async-func), or in docs that explain why it doesn't work.

The question for me is why function doesn't work

 - actually, function in R3 works better than in R2! However, that 
 still is far behind closure.

Ladislav: "** Script error: a word is not bound to a context. -That 
is actually better than what you get in R2" Why is that?

This is what you get in R2:

f: func [a [number!]] [func [b [number!]] [a + b]]

g: f 1

h: f 2

>> g 1 
== 3

, this is much worse than error!

(1 + 1) surely isn't 3

I don't agree, because 'H is defined within context of 'G and uses 
'H binding.  its both consistent and logical... because Rebol binding 
is supposed to be static.

in the above example, I'd say the construct itself does what it should, 
but the real question is should one usually do this... no.  


I understand its a trap, but its not a trap for which the language 
is responsible, the user is simply leveraging the language.

you have two functions which share a parent context.

I do not need explanation, I can give it as well. The problem is 
not explanation, the problem is expectation.

ah... but expectation has nothing to do with implementation or logic. 
  expectation is *SOLELY* related to prior knowledge.   so this is 
not a question of what *it* should do  but of what *you* expect it 
should do.    :-)

Wrong addressee. I do not expect anything at all as I proved. What 
Pekr, Cyphre or other users expect is "real" to me, though.

Closure is my "child" in a sense. I wrote it because I found it is 
what people want to have.

(instead of "explanations")

have you tested how much overhead it causes on evaluation?

As I said, it depends on the implementation, which may need more 
optimizations...

(I wrote only a mezzanine "template", and suggested some tricks, 
but Carl wrote the actual implementation using my hints)

Did you test it?

cause in my tests, binding is the single most demanding (low-level) 
operation for the interpreter.  I am not trying to debunk your efforts 
for closure, which *should* be used more, I am just curious as to 
the impact it causes in real life.

OK, any test results?

As I mentioned, I already gave Carl an advice how to speed up binding 
in R3 substantially when compared to R2

...and I know he used my advice obtaining a noticeable improvement

OTOH, there is still one trick that can be used to speed up rebinding 
in closure case.

testing of binding itself on class vs prototype based oop for Rebol 
was several orders of magnitude when dealing with large objects. 
 both in speed and RAM.  I admit my tests are more on the extreme 
side of things, with the object in question taking up 80kb of RAM 
for every new instance.


but when grouping up the functions of the object into a "sub" object, 
like face/feel, instead of letting them live within the face itself, 
speedup was exponential.

at 1000 objects it was probably about 10 times faster, at 10000 objects 
it was about 25 times faster and I couldn't even allocate 100000 
prototype objects and it crashed after a full 76 minutes of crunching 
at 100% CPU.  a 1'000'000 object test with "classes" took 4 minutes 
and 400MB... so you can see that binding is a very significant part 
of the processing of Rebol, when it is required often.


obviously, some peeking into the C sources will allow us to optimize 
all of this, (especially if it can be memcopied directly)  but by 
default, as in R2, closures would theoretically be quite a hit in 
performance.

So, obviously, totally unrelated tests.

related, tests which show that run-time rebinding must be avoided 
at all costs.   if closures are forced to rebind, there will be a 
hit.


my question was initially to know if you had done tests with closure 
itself... cause I  am curious how well it compares to the default 
case of doing it all on the interpreter side.

I see no point in:


- testing in R2 where the native implementation of closure does not 
exist

- testing in R2 where the binding algorithm is substantially slower

- using test R2 results for faces to infer about R3 implementation 
of  closures

R3 A111 / Linux-x86:
>> f: func [x y] [x + y]
>> dt [loop 1'000'000 [f 10 20]]
== 0:00:00.18006
>> q
>> c: closure [x y] [x + y]
>> dt [loop 1'000'000 [c 10 20]]  
== 0:00:00.882204

R3 master, current rebolsource.net build for Linux-x86:

>> f: func [x y] [x + y]
>> dt [loop 1'000'000 [f 10 20]]
== 0:00:00.158908

>> c: closure [x y] [x + y]
>> dt [loop 1'000'000 [c 10 20]]
== 0:00:00.279227

Well, stupid measurements, sorry. The A111 measurement is an outlier. 
Need to do more statistically sound measurements.

f: func [x y] [x + y]
c: closure [x y] [x + y]
loop 30 [
    print [
        dt [loop 1'000'000 [f 10 20]]
        dt [loop 1'000'000 [c 10 20]]
    ]
]

R3 A111 Linux-x86:
function: 0.16014277 avg
closure: 0.29911023 avg
86.7% +/- 1.6% difference at 99.5% confidence (t-test)

It would be interesting to see how that difference varies as the 
complexity of the body increases.

Here is an example with a complex body:

f: func [n x y] [
	loop n [
		loop n [
			loop n [
				x + y
			]
		]
	]
]

c: closure [n x y] [
	loop n [
		loop n [
			loop n [
				x + y
			]
		]
	]
]

>> time-block [f 10 10 20] 0,05
== 0.00017675781250000002

>> time-block [c 10 10 20] 0,05
== 0.000158203125

the closure is more efficient?