Why do **2 and ² behave differently when using the cross meta-operator?

Question

The outcome are the same under currying,

say map * **2 , 1, 3, 5, 7, 9;
(1 9 25 49 81)
say map *² , 1, 3, 5, 7, 9;
(1 9 25 49 81)

On the other hand, the behaviors are different via the cross meta-operator,

say 1, 3, 5, 7, 9 X**2;
(1 9 25 49 81)
say 1, 3, 5, 7, 9 X²;
((1 2) (3 2) (5 2) (7 2) (9 2))

Why do **2 and ² behave differently when using the cross meta-operator?

Answer 1

The X metaoperator takes the two lists it's given a combines them using the operator you give it. If you don't give it an operator it uses , as the default.

So in this case :

say 1, 3, 5, 7, 9 X²

The X metaoperator is looking for an infix operator. ² isn't an infix operator it's postfix.

So X applies , as the operator. But now ² is being evaluated as a list and in this case it's "this the number 2" property kicks in.

Basically these are the same :

say 1, 3, 5, 7, 9 X²
say 1, 3, 5, 7, 9 X, 2

If you want to square all the items in a list you want to use a map operator. As you did at the start.

Answer 2

Meanwhile on IRC

<Doc_Holliwood> m: ².WHAT.say
<camelia> rakudo-moar ed8f5141f: OUTPUT: «(Int)␤»
<Doc_Holliwood> m: say 2 - ²
<camelia> rakudo-moar ed8f5141f: OUTPUT: «0␤»
* abraxxa has quit (Ping timeout: 252 seconds)
<Doc_Holliwood> where is the magic?
<Doc_Holliwood> m: 2².say
<camelia> rakudo-moar ed8f5141f: OUTPUT: «4␤»
<jnthn> I don't think there's any magic at all, it's just falling out of the standard parsing rules
<AlexDaniel> u: ²⅓
<unicodable6> AlexDaniel, U+00B2 SUPERSCRIPT TWO [No] (²)
<unicodable6> AlexDaniel, U+2153 VULGAR FRACTION ONE THIRD [No] (⅓)
<Doc_Holliwood> somewhere something must be actively distinguishing
<AlexDaniel> so any No has a numeric value
<jnthn> Well, the parser knows when it's looking for a term and when it's looking for a postfix
<AlexDaniel> you can use these unicode characters (that are No) as numeric literals
<AlexDaniel> and yeah, what jnthn said :)
<jnthn> It can't be looking for a postfix if it didn't yet see a term
<AlexDaniel> we had a few tickets about this, people find it very surprising, but the parser doesn't
<Doc_Holliwood> so ² is sometimes an int and sometimes its a postfix depending on context?
<tobs> by the same rule, it can distinguish between multiplication and whatever star
<AlexDaniel> well, similarly, yes
<AlexDaniel> m: say (* * *)(2, 8)
<camelia> rakudo-moar ed8f5141f: OUTPUT: «16␤»
<jnthn> Doc_Holliwood: I guess, though only in the same sense that "+" in +$x is the numify operator, but in $a + $b it's the infix addition operator.
<tobs> m: say 2²⁰
<camelia> rakudo-moar ed8f5141f: OUTPUT: «1048576␤»
<jnthn> In general, the parser is always quite clear about what category of thing it would like to see next.
<AlexDaniel> m: 2 2
<camelia> rakudo-moar ed8f5141f: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> 2⏏ 2␤  expecting any of:␤        infix␤        infix stopper␤       statement end␤        statement modifier␤        statement modifier…»
<AlexDaniel> m: * 2
<camelia> rakudo-moar ed8f5141f: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> *⏏ 2␤  expecting any of:␤        infix␤        infix stopper␤       statement end␤        statement modifier␤        statement modifier …»
<AlexDaniel> m: × 2
<camelia> rakudo-moar ed8f5141f: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Preceding context expects a term, but found infix × instead.␤at > <tmp>:1␤------> ×⏏ 2␤»
<AlexDaniel> the error messages make it quite transparent :)
<Doc_Holliwood> I'm just trying to wrap my head around the latest SO question. but it makes sense to me now. if ² ist a postfix, but X requires an infix. so X² cant DWTHAM
<Doc_Holliwood> in order for say 1, 3, 5, 7, 9 X² to be 1 , 25, etc you would need to change how X works 
*** <jnthn> m: say (1, 3, 5, 7, 9)>>² ***
<camelia> rakudo-moar ed8f5141f: OUTPUT: «(1 9 25 49 81)␤»
<jnthn> Just use something that expects a postfix op :)