HaloO, Jonathan Lang wrote:
I agree that the distinctions between the five different equality tests (=:=, ===, eqv, ==, eq) are rather difficult to grasp (I'm still having trouble getting the difference between '===' and 'eqv', and would appreciate some help).
So let's try to join our half knowledge, then! Here's my half. The deep comparison operator eqv is relatively easy. It traverses references until it has evaluated complete tree values that are then compared. I'm unsure if e.g. 0..Inf eqv 0..Inf works without looping endlessly. IOW, does eqv cause lazy values to be calculated or can it compare them shallowly? The === operator is supposed to stop traversal when it hits a container and use the identity of the container. So with +(@a,@b) == 2 because the arrays aren't flattened (are they?) we get @x = (@a,@b); # @x has two arrays as content, I hope. @y = (@a,@b); # Or does that need \(@a,@b)? If yes, add it. say @x === @y; # true irrespective of contents of @a and @b I hope that helps and is correct in the first place.
By changing things around so that what's currently called 'eqv' is instead called '==', and the current '==' and 'eq' get replaced by '+==' and '~==' (which would be "diagonal") or are removed altogether (which would be "orthogonal"),
I would use orthogonality in the sense that it spawns a new dimension. That is the first dimension is the comparison operator <,>,<=,>=,== and the second dimension is the choice of type enforcement: none, +, ~ or ?. BTW, we should also allow meta ! versions !<, !>, !<= and !>= for completeness. How about the int context enforcer? I can think of int== being useful. Another advantage of the meta operator approach is that it can be applied for other operators as well. So one can always force dispatches to &infix<op>(Num,Num) with +op etc.
the analogies between the various equality tests become more intuitive: '==' and '===' are different variations of 'test for equality of value' (again, I'm not quite clear on how they differ),
You mean == becomes what === is right now and the new === takes over the deep semantics of eqv. All letter ops are dropped. Right? Well, for now we have got two new letter ops before and after. I wonder how much code will be written with these just to become independent of the enforcement of numeric comparison. This actually raises the question if the numeric comparison operators can just be overloaded and dispatched as normal. IOW, is the numeric comparison achieved in standard Perl 6 by providing a :(Num,Num) target and a corresponding proto that enforces Num and re-dispatches? Or is the numeric enforcement more hard-wired, e.g. in the parser? Regards, TSa. --
