Re: deciphering infix:cmp

[David Green]

On 2009-Mar-26, at 10:50 pm, Patrick R. Michaud wrote:
But what to do with something like C 3 cmp '3' , or any   
infix:cmp where the operands are of differing types? Do we  
constrain Ccmp to only work on similarly-typed operands (in which  
case my sort above would fail), or am I overlooking something obvious?


Failing makes sense to me (you can't compare apples to oranges, at  
least not without explicitly saying you want compare them only as  
coerced to general Fruit types).  The other way I can think of that  
might be useful practically is to compare first by type, then by  
value; but that should probably be a different operation.


say sort { $^a.WHAT leg $^b.WHAT || $^a cmp $^b }, a, 1, b,  
2 , c, 3, d, 4;




-David

Re: deciphering infix:cmp

[Jon Lang]

In the case of strings and numbers, I'd recommend using leg instead of
cmp - that is, coerce both items to strings, then compare the strings.
 But as far as cmp goes, 3 cmp '3' should fail because a number
isn't a string.

-- 
Jonathan Dataweaver Lang

deciphering infix:cmp

[Patrick R. Michaud]

Rakudo gives some strange results when sorting a list
of mixed strings and numbers, which leads me to look
for some clarification on infix:cmp (which S03:2866 says
that sort uses by default).   Here's the case I found
in Rakudo:

   say ('a', 1, 'b', 2 , 'c', 3, 'd', 4).sort.perl;
  [a, b, c, 1, 2, 3, 4, d]

After tracking it down a bit -- it's not clear what
infix:cmp should do when given arguments of differing
types.  S03:2855 says:

Binary Ccmp is no longer the comparison operator that
forces stringification.  Use the Cleg operator for the old Perl 5
Ccmp semantics.  The Ccmp is just like the Ceqv above except that
instead of returning CBool::False or CBool::True values it always
returns COrder::Increase, COrder::Same, or COrder::Decrease
(which numerify to -1, 0, or +1).

So, since Ccmp is just like Ceqv, here's the definition of Ceqv
for immutable types (S03:2829):

Binary Ceqv tests equality much like C=== does, but does
so with snapshot semantics rather than eternal semantics.  For
top-level components of your value that are of immutable types, Ceqv
is identical in behavior to C===. 

And if we look at C===, we have (S03:2802):

Binary C=== tests immutable type and value correspondence:
for two value types (that is, immutable types), tests whether
they are the same value (eg. C1 === 1); [...]
Two values are never equivalent unless they are of exactly
the same type.

This means that C 3 === '3'  would be false, and
since Ceqv is identical to C=== for immutable types,
C 3 eqv '3'  would also be false.

But what to do with something like C 3 cmp '3' , or any 
infix:cmp where the operands are of differing types?
Unlike Ceqv and C=== that can simply return false for 
arguments of different types, Ccmp wants to return an
ordering.  Do we constrain Ccmp to only work on similarly-typed
operands (in which case my sort above would fail), or am I 
overlooking something obvious?

Pm