World: r3wp

It's a recent bug fix. Wait, isn't STRICT-EQUAL? supposed to be EQUIVALENT? 
plus a datatype check? Then if EQUIVALENT? already does zone math 
I vote that STRICT-EQUAL? do zone math and SAME? do precise equivalence.

Wait again, == also does case checking. Does EQUIVALENT? do case 
checking?

Equivalent?: ignores datatype differences, alias distinctions, character 
case differences

so, more differences between Strict-equal? and Equivalent?

Then this seems like a good add, unless it is reserved for =?

you mean to add the distinction of timezone to Strict-equal? - yes 
looks natural

t/zone = none - how did you get that?

Yeah. (Bad hand, bad keyboard day)

OK, *adding the timezone distinction to Strict-equal?*

BTW, I should probably put the tests away from the main article, 
otherwise it is quite unmanageable, what do you think?

Oh, the t/zone is really d/zone - it's a date! thing, recently fixed.

Please moo their own page.

yes, but still, it is not none, but 0:00

moo -> move the tests to. Bad AltMe as well.

OK

You're right:
>> d: 12-Jan-2000
== 12-Jan-2000
>> d/zone
== none
>> d: 12-Jan-2000/1:00
== 12-Jan-2000/1:00
>> d/zone
== 0:00

Current build, don't know about after Carl's current changes.

d/zone  = none is related to the d/time = none, yes

("pure" date)

So apparently the time zone is never none, but the whole time in 
date! may be none.

this is discerned by Equivalent? already, otherwise it would not 
be transitive

Ladislav, check bug#1049 - I added a new comment. We need to discuss 
this.

this is already done by MOLD, so it is present

(I mean the marking)

...as well as collect-words, etc....

Mold does cycle detectionn, but not cycle comparison. Mold gives 
up when it detects a cycle.

EQUAL? would have to detect whether the cycle was the equivalent 
reference to the cycles of the other block.

yes, but the detection uses the Marking algorithm, nevertheless (at 
least AFAIK)

so, the same approach as for MOLD

That will have to change when task! is fixed.

hmm, marking is used for Collect-words and some other things, too

and GC, of course

These would all need to be considered EQUAL?:
>> a: [z] append/only a a
== [z [...]]
>> b: [z [z]] append/only second b second b
== [z [...]]
>> c: [z [z]] append/only second c c
== [z [z [...]]]

Simple cycle detection wouuldn't help there - you would need cycle 
tracing.

that depends on the quantity of marking bits, if you have only one 
marking bit, you can just detect cycle, if you have 32 bits, you 
can detect the index

Cycle detection would be good enough to let you throw an informative 
error though, without getting as far as a stack overflow.

btw, in the Identity article I wrote an equivalent? version, that 
works with cyclic structures

(but it is slow, not having any additional marking data available)

Ladislav, the cyclic structures above are not the same structure, 
but the results would need to be considered EQUAL?. Unless we declare 
that cyclic structures need to have the same structure to be declared 
equal - then we can use a stack of ref/index for the structure detection.

Simple marking wouldn't work, unless we locked the data for the task 
first.

Since that data is complex and has references such marking couuld 
easily deadlock.

It all depends on how sharing of data between tasks is done. It looks 
(currently) like Carl is thinking that PROTECTed series would be 
sharable - this would mean that large swaths of the data in memory 
would be unmodifiable, or duplicated. This makes functional or lock-free 
datastructures even more important for R3.

Updated the comment according to the above discussion.

Simple marking wouldn't work, unless we locked the data for the task 
first.
 - that has to be done for the GC as well as for MOLD etc. anyway

Yeah, buut that would only help for cycle detection, not for structural 
equivalence.

try this in R3


>> do http://www.rebol.org/download-a-script.r?script-name=identity.r
Script: "Identity.r" Version: none Date: 7-May-2009/8:59:07+2:00
Script: "Contexts" Version: none Date: 12-May-2006/15:58+2:00
Script: "Closure" Version: none Date: 11-May-2009/19:13:51+2:00
Script: "Apply" Version: none Date: 7-May-2009/9:25:31+2:00
== make function! [[
    "finds out, if the VALUE is mutable"
    value [any-type!] /local r
][
    parse head insert/only copy [] get/any 'value [

        any-function! | error! | object! | port! | series! | bitset! |
        struct! | set r any-word! (
            either bind? :r [r: none] [r: [skip]]
        ) r
    ]
]]

>> a: [z] append/only a a
== [z [...]]

>> b: [z [z]] append/only second b second b
== [z [...]]

>> c: [z [z]] append/only second c c
== [z [z [...]]]

>> equal-state? a a
== true

>> equal-state? a b
== true

>> equal-state? a c
== true

Apply and Closure not needed, but the script was written for R2

Mere cycle detection is only good enough to throw a good error. To 
determine equivalence you need to compare different cycles to see 
if  they are the same shape. Or topologically equivalent if you are 
ambitious.

as I said: if we have 32 bits available for marking, it *is* enough

(and, said 32 bits are needed only for block-like data values, for 
other values, like objects, one bit is plenty)