REBOL3 tracker
  0.9.12 beta
Ticket #0001834 User: anonymous

Project:



rss
TypeWish Statuswaiting Date20-Jan-2011 23:26
Versionalpha 110 CategoryNative Submitted byBrianH
PlatformAll Severitymajor Prioritynormal

Summary Tweak STRICT-EQUAL? equivalences, add STRICT-EQUIV? function
Description 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
Example code

			

Assigned ton/a Fixed in- Last Update28-Feb-2014 23:54


Comments
(0003044)
BrianH
20-Jan-2011 23:31

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.
(0003054)
Carl
30-Jan-2011 20:26

Under consideration, if a satisfactory solution is agreed by Ladislav.
(0003058)
BrianH
30-Jan-2011 21:35

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.
(0003077)
Ladislav
31-Jan-2011 12:11

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.
(0004279)
BrianH
28-Feb-2014 23:54

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.

Date User Field Action Change
28-Feb-2014 23:54 BrianH Comment : 0004279 Added -
16-Feb-2013 03:09 BrianH Description Modified -
31-Jan-2011 12:11 Ladislav Comment : 0003077 Added -
30-Jan-2011 21:37 BrianH Comment : 0003044 Modified -
30-Jan-2011 21:35 BrianH Comment : 0003058 Added -
30-Jan-2011 20:26 carl Comment : 0003054 Added -
30-Jan-2011 20:25 carl Status Modified submitted => waiting
21-Jan-2011 00:50 BrianH Description Modified -
21-Jan-2011 00:41 BrianH Description Modified -
21-Jan-2011 00:33 BrianH Description Modified -
21-Jan-2011 00:27 BrianH Description Modified -
20-Jan-2011 23:35 BrianH Description Modified -
20-Jan-2011 23:32 BrianH Description Modified -
20-Jan-2011 23:31 BrianH Comment : 0003044 Added -
20-Jan-2011 23:27 BrianH Severity Modified minor => major
20-Jan-2011 23:27 BrianH Description Modified -
20-Jan-2011 23:26 BrianH Ticket Added -