World: r3wp

Then again, R2 has surprised me with my current project

networking is not a strong point

Geomol, your last "potential problem with ALSO" is not exclusive 
to ALSO. It's a potential problem anywhere COPY is abused by a programmer 
not knowing what's going on.

The way to return the large amount of data and to release the local 
from it is of course like this:

	also local-data local-data: none

load-mp3-data: func [file /local contents][
	contents: read/binary file
	; <- modify contents here
	also contents contents: none
]

data: load-mp3-data %song.mp3

so this frees contents??

just to say there is no need  anymore to unset the local vars in 
R3

In the load-mp3-data function above, a large binary series is loaded 
and contents set to refer to it. The ALSO line returns the binary 
series and unsets CONTENTS so that it no longer refers to the binary 
series. The usage code below the function definition takes the return 
value (the binary series) and sets DATA to it.

So effectively the variable referencing the binary series has been 
switched with another one.

(Steeve, yep.)

Graham, no, it just "unhooks" the local word CONTENTS from the binary 
series data.

Which is a good thing to do, because now the function does not maintain 
a reference to the large binary series after it has been called.

If the contents var is not unset and then the load-mp3 function is 
not anymre called.

Then, the garbage collector can't free the serie because it stays 
handled by the local var contents.

Hmm.  So, one should deference local vars if they pointing to large 
data sets?

dereference

yes, In R2 we should

Steeve, yes, that's right.

didn't know that ...

Yes, in R2, functions don't bother to unset their local words on 
function exit. This was done for speed reasons. Most functions don't 
need to unset their locals.

I wonder if that would help with the problem I had before when I 
was doing OCR on image data .. and kept getting crashes

Where you running out of memory?

no

*Were you..

If I turned off recycle, the problem disappeared, but then memory 
eventually would run out

That was more likely some external library call problem.

not using external libraries

I was posting the data to a web server

web service

That was a memory leak, not really caused by the "local vars not 
unset on R2 function exit" behaviour. (But perhaps contributed, by 
misunderstanding, to the leak bug.)

Yes, Graham we need to clear those locals by setting them to none.

I use ASLO in R2-Forward for that reason - that was the original 
reason ALSO was suggested. You don't need ALSO for that in R3 since 
the locals unset themselves in the new function context model, but 
it is useful for closing ports and changing directories back.

Brian, are the parameters in R3 also unset in R3?

R3 has stack frames, so the entire frame - including the locals - 
is tossed after the function returns.

Closures are different though - a whole new context is created with 
each call, words and values both.

Closures are for doing "memory leaks" on purpose :)

Will we get any control over the stack?  So that we can potentially 
perform recursive operations without overflow?

Unlikely, since most tail recursion optimizations require an optimizer, 
or at least a compiler. Manual access to the stack is a security 
hole (unless the language is Cat). Accept that REBOL has real loops 
and that imperative programming is more efficient in an interpreted 
language :)

REBOL was designed to be interpreted efficiently. Don't compare it 
to languages that were designed to be compiled (like Haskell) or 
languages that aren't designed for efficiency (like Scheme).

Yeah I understand that.

REBOL 1 had tail-recursion optimizarion. REBOL 2 got rid of it on 
purpose, and got 30 times faster as a result :)

There were some other tricks that contributed, like getting rid of 
continuations and ELSE.

Carl sharing this much with you or how do you know this about REBOL?

I was one of the beta testers of REBOL 2 - I've been around that 
long :)

I can't remember what version I started with REBOL in.  I just know 
the year was 98.

But I walked a way a bit at times as the lack of development waned.

Earlier than me - I started in 99, with REBOL 1.0.3.

I remember back then we had Holger, Jeff, and Sterling.

I miss those guys. The beta list for R2 started a month after I arrived.

Yeah I found out about REBOL through a listserv I was on at the time 
with a bunch of Cisco Engineers.

I think I saw it mentioned on Usenet. We had Joel Neely too - he 
wrote the R1 interpreter, which was so slow (because it was like 
Scheme) that Carl had to rewrite it from scratch: REBOL 2. That is 
why Neely flames REBOL on the Scheme lists.

(I may have the name wrong though - I'm really bad at names.)

Wow, I remember that name but didn't know about the flames.