Actionable Raku(do) issues

[2colours]

Hi,

I intend this to become a collection of Raku(do) issues that are (or at least seem to be) well understood enough to resolve one way or another - if there is enough of a will.
Feel free to post issues like this if you have examples.

[2colours]

Let me start: rakudo/rakudo#5126

I investigated this even back in the day but I think now I have more confidence to summarize the situation.

1. my int @array would be a "native array" (typed array[int])
2. similarly has int @.items creates @!items as array[int] and it creates an accessor method items (here, I don't expect is rw to have any effect on an array)
3. within the class, @.items can be now used as a synonym for @(self.items) or spelt differently: self.items.list
4. the .list context of an array is List - this is quite explicit in the code
5. usual Arrays go unmodified because they fall back to this call - that's why the same code would have worked with uppercase Int and Array
6. the current .STORE behavior on the created List breaks - basically we try to assign "emptiness" (Nil) to fixed, native int slots

One can see that the behavior of array and Array is different here. One way to resolve the issue could be to say that all these steps and the apparent inconsistency are intended. Otherwise, the modifications could have, intended or unintended, side effects:

• changing the .list behavior of arrays - I think this would be the way to go, although the current behavior (and the reason for that) would have to be investigated
• changing the .list behavior of Arrays absolutely unfeasible, this is too essential and perhaps even intended
• altering the .STORE behavior of Lists so that it can shrink the native int slots - I think this is both more costly and hacky than the first choice

[2colours]

rakudo/rakudo#5882

As noted, this regression seems to come from this commit, line 497 tries to do too much: the first result should indeed be $operator($value) but the first value in the argument list should be just $value, or else it's the list (1) that becomes the first argument, rather than 1.
Within the method pull-one, one can see this mistake is not repeated: the value pushed to the argument list is the value pulled from the input, without any transformation.

[2colours]

Fixed as per rakudo/rakudo@9564c4fdc6 (Roast extended with this particular example)

[2colours]

rakudo/rakudo#2587

The technical side seems simple, the conceptual side much less so.

In a couple of layers, these mapped zip calls arrive here and for list associative operators (or whatever is actually recognized as such... this could be a whole other topic) the list is just passed as one single argument, as-is. I'd argue this is unintended and the values in the list should be passed on one by one, slipped. In any case, this way, we hit this call that somehow produces a sequence consisting of the values that went in; I'd say that part is not very interesting anymore.

[2colours]

I found a related issue: rakudo/rakudo#5227

This actually works now - but I wouldn't suggest to close it. The associativity of the affected operators has changed. (This is what I meant by "whatever is actually recognized as such".) Apparently in the new operator model, there are random changes to how operators work...

Anyway, knowing this, xor for example, or ^^, are still problematic - but only with the sub call, not with Z^^. That's presumably still because of their thunkiness, just like originally for Z&&. There is no such thing that could remedy Z....

[2colours]

So let me summarize the situation for the lols:

• there are operators like +: it has "always" worked well because it's left associative and a good call is generated
• there are the ones like xor or ^^: eg. Zxor works but not zip(...,, with => &[xor]) - list associative but also "thunky" and the Zxor case generates a different (better-working) call for those...
• there are the likes of and and || that work now: because they got - silently, as far as I can tell - changed to left associativity with the new RakuAST operator design
• there's & which is both list associative and non-"thunky", yet it works with both types of calls - because the signature of the operator itself follows the single-argument rule, hence unwrapping the received list 🧠
• and then there is ... which is list associative, it isn't "thunky" and indeed it doesn't work with either call because its convoluted logic just produces the input list as a sequence