Por que ** 2 e ² se comportam de maneira diferente ao usar o meta-operador cruzado?


8

O resultado é o mesmo em 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 outro lado, os comportamentos são diferentes através do meta-operador 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 que ** 2 e ² se comportam de maneira diferente ao usar o meta-operador cruzado?

Respostas:


9

O Xmetaoperador pega as duas listas e as combina usando o operador fornecido. Se você não fornecer um operador, ele usará ,como padrão.

Então, neste caso:

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

O Xmetaoperador está procurando um operador de infixo. ²não é um operador de infix, é um postfix.

O mesmo Xse aplica ,como operador. Mas agora ²está sendo avaliada como uma lista e, nesse caso, é a propriedade "este o número 2".

Basicamente, são os mesmos:

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

Se você deseja enquadrar todos os itens em uma lista, deseja usar um mapoperador. Como você fez no começo.


4

Enquanto isso, no 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 :)
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.