World: r3wp

blog updated: "Closure Functions"

request for R3   rebcode access to struct! types.

would allow us to implement specific mechanisms very quickly and 
gauge memory useage tradeoffs vs speed depeding on application.

It has been suggested before in the rebcode group (mostly by me) 
when rebcode was first being developed. I think there are RAMBO entries 
too.

lets all kick and scream in unison  ;-)   maybe we'll make more noise 
and rattle than all the other requests  ;-)

What's an example of how having closures will aid us ?

I think they said they needed closures for threading.

That's right, so a function could be interrupted mid-evaluation and 
restarted later.

closures haven't much to do with threading. although they are reentrant, 
while normal funcs are not (in r2; I guess it may be possible to 
make normal funcs reentrant in r3).

closures help when you want the function's context to be valid for 
an indefinite amout of time.

so, a function that maintains state ?

wasn't "indefinite extent" available in R1? just curious if it is 
similar concept?

I think you are thinking of continuations.
Closures are much more lightweight.

petr, yes, functions in r1 were actually closures. (as functions 
in lisp or scheme)

weren't they removed for 2.0 because of speed aspects?

yes, but that was not the only speed problem in r1

and, speed is the reason why you have both function!s and closure!s 
in r3

you normally use function!s that are faster

and use closure!s only when you are ready to pay the price for them 
:)

oh yeah... continuations.. oops.

don't closures also help with the copy problem?  where each time 
you run the closure, a series is indeed new?

Is there a succinct way of demonstrating a situation where a closure 
would be used (with hypothetical Rebol code)?

f: closure[ta][
 view layout [ta: area]
]

and might I ask what is the purpose of setting 'ta ?

having a local

making multiple layouts this way.

It's the layout and not 'ta that is returned though?

yes. more explicit:

f: closure[ta sl][
 view layout [ta: area sl: slider [scroll-para ta sl]]

to make some use of that local.

Is that just another way of wrapping locals in an object?
f: context [ta: none view layout [ta: area]]

ok, yes, currently only one slider will work (the last one called)

Yes, exactly.

yes, its a context within a function.

What are the advantages over creating an object! context?

I guess shortcut-things and a little speed. and i made a mistake, 
my example must be
 f: closure[/local ta sl]

so if
   f: closure[arg1 arg2 /local ta sl]

would be automatically in the context. Currently we must pass as 
function-arg and put it in context by hand

ah... volker... that was the basis of my question  ;-)

Aah, so you got my example better than me! :)

Maxim: no, it does not solve the copy problem; however, closures 
need to copy deep the function body at each call; so, it somewhat 
solves the copy problem as a side effect (only for blocks and parens 
though, probably, as there's no need to copy anything else). (however, 
i would not rely on it, since for example it would be a useful optimization 
not to copy empty blocks or blocks that contain no words etc)

about an example where closure would be used, the classic example 
is:

make-adder: closure [n] [func [x] [x + n]]

add-10: make-adder 10
add-2: make-adder 2

add-10 5 ; == 15
add-2 3 ; == 5

notice that this fails with func instead of closure.

well I didn't say "solve"  ;-)  but by what I understand of closures 
(and I have been reading a lot lately) if 'closure does a deep copy 
without empty series optimisation, then we could rely on it.


actually, NOT copying empty series would make closures bugged, since 
all generated closures would referrence the same empty block from 
the context of the closure's definition.  which is in direct contradiction 
to the concept no?

Personally, I've never really considered the "copy problem" a problem. 
When you don't copy something it doesn't get copied. When you do 
it does. Series aren't immediate values, they are reference values. 
Same for objects. Every language design choice could be considered 
a bug or a feature - it all depends on how you use it. I've found 
more advantages to the way that REBOL functions work now.


The only real problem I've run into is functions keeping references 
to their temporary data after they return, at least until they are 
run again (a memory hole). The closure example above with the adders 
stops being a problem when you realise that FUNC is a function that 
does something when passed a  couple blocks - it's not syntax. You 
didn't copy the block, so it gets reused, go figure. You are building 
functions - is it such a stretch to build code blocks?

make-adder: func [n] [func [x] compose [x + (n)]]

brian I agree completely.  I love REBOL's ultra consistent reference 
mechanism.  on the R3 blog, I noted how python copies everything 
and how it becomes tiring to upkeep all the time.

and for the record, I hate the fact that I have to return first reduce 
[value value: none] all the time.  its slow, ugly and its a BIG memory 
hole in view and something within the stylesheet system.

so if we now have real closures in R3 can we have real /locals in 
functions?  which explicitely remove themselves from the stack on 
function exit?

and thus get tackled by the GC?

Let's suggest that to Carl in the Closure comments.