World: r3wp

(differs from the current behaviour)

are there other votes for the change?

I would have thought EQUIVALENT? would imply the same time zone, 
or at least some time zone math. Certainly STRICT-EQUAL?.

differs from the current behaviour

 - The time! type is being rewritten right now because itts current 
 behavior is bad.

Equivalent? - it would use time zone math, even EQUAL? now uses time 
zone math:

>> equal? 7/7/2009/10:00 7/7/2009/10:00-02:00
== false

>> equal? 7/7/2009/10:00 7/7/2009/8:00-02:00
== true

(i.e. UTC is compared)

As long as no zone is equal? to zone of 0:00 I am happy.

no zone is actually 0:00 zone

>> 7/7/2009/10:00/0:0
== 7-Jul-2009/10:00

t/zone = none, but basically yeah

aha, did not notice, that there are actually two zones: zone = 0:00 
and zone = none

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.