World: r3wp

Even then, it is not very efficient. You are better off clearing 
select words explicitly.

This is part of why R3's function contexts are different: to make 
this kind of thing unnecessary.

As a side effect, the clear-words function would be impossible in 
R3.

What part would be inefficient?

Getting a the argument list, which you would have to copy, convert 
refinements to words, then bind. The copy and conversion would be 
slower than necessary.

Yeah I don't know if the overhead is worth it.

R3 in 09?

Hmm..  I should sell T-shirts with that on it.

Developer releases at least, and maybe before then.

Everyone would ask "What is R3?" and then we could tell them about 
REBOL.

>> myfunc: func [arg /local lcl lcl2][
[        lcl: "I still have a value"
[        lcl2; 2
[        clear-locals :myfunc lcl
[        print lcl
[        print lcl2
[    ]
>>
>> myfunc 2
none
none
>>

typo in my function

>> myfunc: func [arg /local lcl lcl2][
[        lcl: "I still have a value"
[        lcl2: 2
[        clear-locals :myfunc lcl
[        print lcl
[        print lcl2
[    ]
>>
>> myfunc 2
none
none

clearly guys, a function should never be so huge and obscufated so 
that it will not be any more interesting to use a clear-locals func.

i meant, it's better to do a my-var: none when necessary

I disagree.

I have 22 locals in one function alone already and even though I 
plan on reducing some of those in reducing some code, I have a feeling 
that I will regain them as I add more code in the function.

for this specific case (lot of locals). you could define a local 
block to reset them simply.
f: func [ ... /local a f g...][
	local: [a f g ...]
	....
	set local none		;clear locals
]

it's enough work

did you know that 'set still works with block of get-words [:a :b 
:c]

REBOL has all kinds of niffty stuff ;-)

What is happening with respect to memory and lower level activity 
when using the 'bind function?

As for the clearing of the locals  from a function - here you go:

clear-locals: func [

        {Used as the ending statement within a function to set the function's 
        locals to none value.}
        fnc [function!]
    ][

        set bind first to-block trim/with mold first :fnc "/" first find 
        second :fnc set-word! none
]

Would make a good mezz for 2.7.7

It can't be made to always work.

There may not be a set-word in the function body.

Anton, in that case wouldn't wouln't have a need to use a clear-locals 
function.

See the answers group as Gabriele posted a superior clear-locals 
function.

Yep, Gabriele got it.

Note that his solution requires the known word parameter, but not 
the function context parameter. This means that it is more easy to 
call from "inside" the function where you can specify a known word 
instead of having to find one. The no-parameter solution is still 
up in the air :)

Just make your own function generator. You can basically inline clear-locals 
into the end of the function body.

There may be some tricky issues to take care of. Refer to Ladislav's 
documents where he does this kind of thing.

Ahh - tricky issue will be how to avoid upsetting the return value. 
Now it looks hard again.

No, it should be easy, just use ALSO with the whole body block.

No, using ALSO isn't so straighforward - it's hard again. :)

do you know why it's returning false ?
>> o: context [b: 1]
>> same? o bind? in o 'b
== false

so currently we have 2 distinct objects with same shared properties

correct.

in R3 it's the same object, so i assume it's a bug in R2

No, I think it goes back to what were discussing in the Answers group.

Read in the Anwers group where we were discussing the affect of 'self 
on the contexts

hum i don't see the relation

Answers (which was intended for responses to challenges in the Puzzles 
group) is not [web-public], so half this discussion is hidden from 
anyone reading just the web archive.

It seems an important technique is under discussion. Could some one 
summarise the state of the art, and continue the discussion here?
Thanks!

Steeve, I guess what I'm saying is that SELF itself becomes a new 
value thus same? would report false.

i see but i'm just asking how it's possible, same? should check the 
inner address of the objects.

if they share the same block! of propertie values it should remain 
equal, no ?

seems there is more indirect links between an object and his properties

But it is checking values.

Self has to be evaluated in that sense to see what value it is in 
each context.

i don't think it's checking values, we have the proof now

2 distinct objects, so that same values in the same memory location 
are not taking in account