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.

Reply via email to