The semantics of >>.foo feel wrong and possibly need changing about problem-solving

[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.

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

[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.