Tweak STRICT-EQUAL? equivalences, add STRICT-EQUIV? function

[rebolbot]

Submitted by: BrianH

Right now the equivalence functions in R3 follow a strict line of increasing equivalence, as documented here: http://www.rebol.net/wiki/Comparisons#EQUAL.3F

However, making STRICT-EQUAL? a superset of EQUIV? has been causing some problems for a lot of programmers that do need what STRICT-EQUAL? adds (datatype, case, alias) but not what EQUIV? adds (binding, exact decimal). This could be solved by adding a new STRICT-EQUIV? function for STRICT-EQUAL?'s current behavior, and having STRICT-EQUAL? be a superset of EQUAL? instead.

This would be the new hierarchy (more of a DAG now):

- EQUAL?: Same as now. Ignores datatypes within certain type classes, bindings, case of strings and characters; considers word aliases to be equivalent (used for case insensitivity of words); uses approximate decimal comparison.

- EQUIV?: Like EQUAL?, but pays attention to word bindings and uses more exact decimal comparison.

- STRICT-EQUAL?: Like EQUAL?, but checks datatypes, and is case-sensitive with words, strings and characters.

- STRICT-EQUIV?: Like STRICT-EQUAL?, but pays attention to word bindings and uses more exact decimal comparison.

- SAME?: Identity, same as it is now.

This behavior would extend to the corresponding NOT-* functions as well. We should also consider whether == should refer to STRICT-EQUAL? or STRICT-EQUIV?, as there is a slight difference between the decimal comparison used by EQUIV? and that used by SAME?. An alternative would be to come up with new operators for EQUIV? and STRICT-EQUIV?, but that has proved difficult so far.

This proposal was suggested by Andreas in AltME. Related: #1133

^{CC - Data [ Version: alpha 110 Type: Wish Platform: All Category: Native Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: BrianH

The main gotcha with this is that the exact decimal comparison performed by STRICT-EQUAL? now wouldn't have an operator, unless SAME? performs the same comparison. Ladislav, is there a difference between STRICT-EQUAL? and SAME? for decimals, and would this be a problem?

(Update) In AltME, Ladislav answered that for STRICT-EQUAL? -0.0 and +0.0 are considered equal, even with the more exact equivalence, while for SAME? they are considered different. If there are more differences he didn't mention them.

[rebolbot]

Submitted by: Carl

Under consideration, if a satisfactory solution is agreed by Ladislav.

[rebolbot]

Submitted by: BrianH

Alternate proposal for the operators: == keeps referring to STRICT-EQUAL? (by the definition in this ticket), === refers to STRICT-EQUIV? and !=== refers to STRICT-NOT-EQUIV?. This lets the majority of programmers continue to use the friendly approximate equivalence for ==, and makes the more exact equivalence available to the numerics people who understand the limits of IEEE754.

[rebolbot]

Submitted by: Ladislav

I am afraid this means a lot of work, while the reasons to do it now are less convincing. Otherwise, I would not object against the proposed hierarchy, if that is what users request.

[rebolbot]

Submitted by: BrianH

Note: "a lot of work" is not a blocker now if there's someone willing to do the work. Yay open source! And this is the exact kind of change that needs to go through before 3.0 - cleaning up basic semantics.