¿Por qué ** 2 y ² se comportan de manera diferente cuando se usa el metaoperador cruzado?

El resultado es el mismo bajo curry,

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)

Por otro lado, los comportamientos son diferentes a través del metaoperador cruzado,

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))

¿Por qué ** 2 y ² se comportan de manera diferente cuando se usa el metaoperador cruzado?

El Xmetaoperador toma las dos listas que se le dan y las combina usando el operador que le da. Si no le da un operador, lo usa ,como predeterminado.

Entonces en este caso:

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

El Xmetaoperador está buscando un operador infijo. ²no es un operador infijo es postfix.

Así se Xaplica ,como operador. Pero ahora ²se está evaluando como una lista y en este caso es la propiedad "este es el número 2".

Básicamente estos son los mismos:

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

Si desea cuadrar todos los elementos de una lista, desea utilizar un mapoperador. Como hiciste al principio.

Mientras tanto en 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 :)