The semantics of >>.foo feel wrong and possibly need changing

[lizmat]

This has been instigated by rakudo/rakudo#5057 .

I've come to the conclusion that my fix for that issue is either the wrong fix, or we need to rethink the semantics of >>.foo. The documentation currently states:

This is the hyper method call operator. Will call a method on all elements of a List out of order and return the list of return values in order.

Now, clearly, that doesn't work for Associatives, as the "elements" of Associatives are Pairs:

$ raku -e  'my $b := <a b c d c d>.BagHash; $_-- for $b; dd $b' 
Cannot resolve caller postfix:<-->(Pair:D);

So Associatives are handled differently by calling the operator on the values of the Associative.

Now let's get back to the original example:

$ raku -e 'say <a b c d c d>.BagHash>>--'                
BagHash(c d)

This now returns what the op expected. But that expectation was actually wrong, because if we do something similar with an array that is created on the fly:

$ raku -e 'say [1,2,3,4,5]>>--'
[1 2 3 4 5]

will return a List of the return values in order And since &postfix:<--> returns the original value, the return value is actually a copy of the original array, and the decrements that have been done, are lost in the ether. If we want to be consistent with that behaviour, then:

$ raku -e 'say <a b c d c d>.BagHash>>--' 
BagHash(a b c(2) d(2))

And those decrements would be lost in the ether as well. And would be contrary to expectations of the op as well.

[lizmat]

Related: rakudo/rakudo@d0ec99a861

[frithnanth]

OK, I understand that it's about the difference between post and pre-decrement.
Obviously (now :-) ) post-decrement returns the original value, then decrements the content of the variable. The pre-decrement does it in the opposite order.
So

$ raku -e 'say [1,2,3,4,5]»--'
[1 2 3 4 5]

while

raku -e 'say --«[1,2,3,4,5]'
[0 1 2 3 4]

Yet doing the same on a BagHash still returns strange results using the stock Rakudo v2022.07:

$ raku -e 'say --«<a b c d c d>.BagHash' 
BagHash(d)
$ raku -e 'say --«<a b c d c d>.BagHash'
BagHash(c)
$ raku -e 'say --«<a b c d c d>.BagHash'
BagHash(c d)

(Those are really three successive tests on my computer :-o )

[lizmat]

That is what commit rakudo/rakudo@d0ec99a861 fixed: rakudo HEAD now says:

$ raku -e 'say --«<a b c d c d>.BagHash'
BagHash(c d)

as expected.

[2colours]

Quoting from https://docs.raku.org/language/operators#index-entry-hyper_%3C%3C-hyper_%3E%3E-hyper_%C2%AB-hyper_%C2%BB-Hyper_operators:

Hyper operators can work with hashes. The pointy direction indicates if missing keys are to be ignored in the resulting hash. The enclosed operator operates on all values that have keys in both hashes.

I think it makes sense that >>. behaves similarly, operating on the values of the Associative data types. I'm not sure if the issue was concerned with this approach but maybe it's good to point out that this seems to derived from related documented behavior.

There are still problems with the semantics/documentation of hyper operators, I wanted to open an issue for that, getting into it now.

EDIT: #346 is ready now.

[raiph]

@2colours

Quoting from [doc]:

The pointy direction indicates if missing keys are to be ignored in the resulting hash. The enclosed operator operates on all values that have keys in both hashes.

Aiui that doc is about binary op hypers ("both hashes", i.e. "missing keys" is about one hash having a key and the other not and so the direction controls whether the mismatch means that element is dropped or not), not unary ops like this issue. I'm not seeing a connection.

[2colours]

@raiph

I am making the connection by saying:

I think it makes sense that >>. behaves similarly, operating on the values of the Associative data types.

Since it seemed the "operating on the values" part may not be written down for the >>. call.