r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

[unknown: 5]
20-Dec-2008
[11787x2]
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.
Steeve
20-Dec-2008
[11789x3]
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]
[unknown: 5]
20-Dec-2008
[11792x2]
REBOL has all kinds of niffty stuff ;-)
What is happening with respect to memory and lower level activity 
when using the 'bind function?
[unknown: 5]
21-Dec-2008
[11794x2]
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
Anton
21-Dec-2008
[11796x2]
It can't be made to always work.
There may not be a set-word in the function body.
[unknown: 5]
21-Dec-2008
[11798x2]
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.
Anton
21-Dec-2008
[11800]
Yep, Gabriele got it.
BrianH
21-Dec-2008
[11801]
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 :)
Anton
21-Dec-2008
[11802x5]
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. :)
Steeve
21-Dec-2008
[11807x2]
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
[unknown: 5]
21-Dec-2008
[11809]
correct.
Steeve
21-Dec-2008
[11810]
in R3 it's the same object, so i assume it's a bug in R2
[unknown: 5]
21-Dec-2008
[11811x2]
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
Steeve
21-Dec-2008
[11813]
hum i don't see the relation
Sunanda
21-Dec-2008
[11814]
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!
[unknown: 5]
21-Dec-2008
[11815]
Steeve, I guess what I'm saying is that SELF itself becomes a new 
value thus same? would report false.
Steeve
21-Dec-2008
[11816x2]
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
[unknown: 5]
21-Dec-2008
[11818x2]
But it is checking values.
Self has to be evaluated in that sense to see what value it is in 
each context.
Steeve
21-Dec-2008
[11820x2]
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
[unknown: 5]
21-Dec-2008
[11822]
The description of same? is this:

Returns TRUE if the values are identical.


if it isn't checking values in each context then how do you believe 
it would be checking the values?
Steeve
21-Dec-2008
[11823]
identical means the inner pointers (in memory) are the same
[unknown: 5]
21-Dec-2008
[11824]
I'm not sure how you can see that the self of one could be the same 
value as a self of another?
Steeve
21-Dec-2008
[11825]
in R3 they do
[unknown: 5]
21-Dec-2008
[11826]
I thought we were talking about R2. Sorry I got confused.  I don't 
know regarding R3.  That indeed could be the case.
Steeve
21-Dec-2008
[11827x2]
i said previously that in R3 (comparing to R2) the bind? function 
returns the same object, not a different one.
i used the first alpha release
[unknown: 5]
21-Dec-2008
[11829]
I'll yield to those that have used the Alpha a bit more as I really 
couldn't speculate at this point even.
Anton
21-Dec-2008
[11830x2]
Steeve, it does look odd, like a bug.
These are ok.
>> same? o do bind [self] o
== true
>> same? o do bind [self] in o 'b
== true
[unknown: 5]
21-Dec-2008
[11832]
If you think it is a bug Anton, then you should report it to Rambo 
assuming your talking about R2.
Anton
21-Dec-2008
[11833]
I leave this honour to Steeve. :)
Steeve
21-Dec-2008
[11834]
boring...
Anton
21-Dec-2008
[11835]
There are no tickets that match a search for "bind?" in Rambo.
Steeve
21-Dec-2008
[11836]
so you are the one who will fill the hole ;-)