World: r3wp

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.

If I got the name wrong, sorry Joel :(

It looks like I *did* get the name wrong. Can't remember the right 
name either, but the flames went on as far as last year :(

Joe Marshal ?

Yeah, that might be it.

Yup, first hit on Google.

Joel Neely works for Fedex

and he too has moved on

Again, sorry Joel. He was fun too - lots of long, essay-like posts.

I think you are thinking of Joe Marshall who worked on an early REBOL, 
and has been critical of his continuations being removed from later 
versions.
http://ll1.ai.mit.edu/marshall.html

(Sorry -- did not see Anton's post  until after I send mine .... 
the old resync bug yet again :)