World: r3wp

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

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?

identical means the inner pointers (in memory) are the same

I'm not sure how you can see that the self of one could be the same 
value as a self of another?

in R3 they do

I thought we were talking about R2. Sorry I got confused.  I don't 
know regarding R3.  That indeed could be the case.

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

I'll yield to those that have used the Alpha a bit more as I really 
couldn't speculate at this point even.

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

If you think it is a bug Anton, then you should report it to Rambo 
assuming your talking about R2.

I leave this honour to Steeve. :)

boring...

There are no tickets that match a search for "bind?" in Rambo.

so you are the one who will fill the hole ;-)

Aha! I like your style of humour! :)

especialy when we know that the word humour has a greek root  meaning 
FLUID

Steeve, o and the result of bind? are the same context but not the 
same object. this is an implementation detail of R2.

I do not think this is a bug, and it may not be trivial to fix it 
if it was (which means, it'll never get fixed as Carl is not going 
to spend that much time on R2 for something not important)

i agree Gab, for me, it's not a bug but a functionnality

What use does it have ?

none for the moment... ;-)

i

in R3 it would be usefull combined with the ability to expand an 
object

it would be something like an inheritance link

a dynamic one

Sure it does - it allows Gabriele's function to work.

don't think it's related

Gabriele's func would work without this

be

besides in R3, the bind? func doen't return a cloned object anymore

Anton, it's not that it has any use, it's that there is no "object" 
internally, just a "context", and the bind? function creates an "object" 
for the "context" so that it can return it (there is no way to access 
a context directly). bind? does not know whether the context is already 
referenced by an existing object or not, nor has any way to get to 
any such existing objects, so it just always creates a new one.

Ahh that makes sense. So yes, an implementation detail of R2.

Has anyone noticed a max length for filenames giving to EXISTS? under 
Windows? I get a false reply, if the length of the full path is more 
than some 54 characters.

Ah, my bad. It works! I had my dir in another place. doh! ;-)

When using local blocks in functions, that is called many times, 
I often define them as:

my-block: clear []

instead of

my-block: copy []


The idea is to reuse the block (the memory area), so the garbage 
collection has less to do. Could there be any drawback in this?

I do the same thing, so I would be interested in hearing about draw 
backs. But it may also be important to specify the size of the block, 
when it's first created. That gives the garbage collector even less 
to do.

Yeah, you don't want to do that.  Because with each loop that evaluates 
the command you actually recreating the pointer.  Instead do this:

my-block: []
...
clear my-block

This way your doing less evaluation.

However, it allows you to be more flexible and possibly save some 
evaluation depending on how you implement it.

Let me give some examples.

Example 1
>> stats/evals/clear
== [1 1 1]
>> my-block: []
== []
>> loop 100 [insert my-block "somedata" clear my-block]
== []
>> stats/evals
== [506 202 103]

Example 2
>> stats/evals/clear
== [507 203 104]
>> loop 100 [my-block: clear [] insert my-block "somedata"]
== []
>> stats/evals
== [604 202 102]

Example 3
>> stats/evals/clear
== [605 203 103]
>>
>> loop 100 [insert my-block: clear [] "somedata"]
== []
>> stats/evals
== [504 202 102]