World: r3wp

so, the question is, how many marking bits are available

Only Carl has that answer. Still reading...

You would have to do something similar to a simplified EQUAL-STATE? 
even in a C version. There will never be enough bits for marking 
because every concurrent instance of your comparison would need its 
own set. Having thread-local done lists would work though.

concurrent instance of your comparison
 -> "concurrently running instance of your comparison function"

concurrently running instance of EQUAL? - yes, understood, that would 
be impossible, but such a thing can be made "atomic/protected", can't 
it?

No.

why? RECYCLE and MOLD will be protected, won't they?

You can make GC single-instance, but not MOLD or EQUAL?. MOLD and 
EQUAL? will be done too often to lock.

too often to lock - I would say, that RECYCLE is more likely to be 
"encountered" than MOLD or EQUAL?

Unlikely - RECYCLE isn't FREE. The whole point to GC is that it isn't 
done that often.

yes, but it takes time: the "probability of encountering" is proportional 
to running time as well as to call frequency

OK, EQUAL-STATE? is too strict in another way: It also considers 
values that precede the series references. I'm going to figure out 
if it will still work if changed to use the level of equivalence 
expected from EQUAL?. Note:
>> equal? next [a a] next [b a]
== true
>> equal? next [a a] next 'b/a
== false
Not sure about that last one - will it be true in R3?

yes, re strictness, it will probably be found too strict in a number 
of ways

What about equal? [a b] 'a/b ?

(it was certainly not a prototype of any specific member of the current 
equality coparison hierarchy)

Are we doing equivalence within any-block! or limiting it to within 
any-path! ?

re last question: supposedly True

(ie. I would take the any-block variant)

but, you may propose a different alternative, if you don't like it 
for some reason

One alternative is equality within any-path!, within any-word! and 
within any-string!, but not within any-block!.

yes, the only difference is, that I considered any-block! to be the 
counterpart of any-string!, but that is just me

Another alternative (the current one) is equality within any-word! 
and any-string, but not within any-block! or any-path!.

I think, that currently the equality within any-string isn't imlemented

sorry for the typos

I consider any-block! and any-string! to correspond as well, but 
the question  is whether EQUAL? should do the same.

You are right about the equality of any-string! - not implemented 
yet.

yes, this needs to be decided specifically for the purpose of equality 
comparison

Remember, EQUAL? is the simplee default for people who don't want 
to worry about things. We have more strictness later down the line, 
buut a little strictness in EQUAL? would help newbies in some cases.

a little strictness in EQUAL? - do you mean, that newbies may be 
more comfortable with finer (stricter) or with coarser (less strict) 
version of EQUAL? in this case?

Yeah. It's hard for me to judge, but equivalence within any-block! 
seems confusing to newbies. However, equivalence within any-path! 
seems to be similar to equivalence within any-word!, so we might 
want to implement it.

We should ask Fork - he seems to be the designated newbie advocate 
these days :)

:-)

ARN (The Association of Rebol Newbies) president

(it is hard for me to understand what he means quite often)

And vice-versa, in my experience, but he's very intelligent so that's 
not it :(

yes, the problem is, that I am used to different terminology

My problem is that my vocabulary is too big and precise for most 
people to get the subtle distinctions :(

I found, that complete newbies are frequently outside of the range 
of my understanding. After discussing a couple of things in the fora, 
they start to become understandable even for me :-)

Most of Fork's recent complaint about tag! in R3 came down to not 
making the distinction between "join" (JOIN and REJOIN) and "adjoin" 
(AJOIN). If he had been around for the discussion that led to the 
creation of the AJOIN function it woldn't have been a problem :(

is seems to be caused by the fact, that I am prepared to assign too 
many possible meanings to their questions to be able to detect what 
they are actually asking

Contextual decoding issues :(

It looks like an algorithm similar to EQUAL-STATE? will work for 
structural equivalence if you get rid of lines 518 and 519. Some 
of the comparisons should be relaxed to the same level as the comparison 
function you are implementing too. I notice that it does topological 
similarity rather than strict structural equivalence :)

yes, but this algorithm is rather slow for Rebol standards?

hmm, seems I am using different line numbering

It will be native (inside the actions). Most of the silly stuff inside 
IDENTICAL? goes away if you are doing C code. The done lists can 
be more efficient too.

The lines to remove:
            a: head :a
            b: head :b

yes, but what about the search? that is O(n)

The done lists can be hashed on the pointer values.

these index issues - there are simply too many variants of equality 
- the Equal-state? comparison is certainly unrelated to any of the 
currently proposed hierarchy levels

(it looks to me like a level slightly above Strict-equal?, but below 
Same?)