@r ,= 'd'; The above expands to:
@r = @r , 'd'; That in turn passes a list of two values to the LHS receiver. That receiver is `@r`, an array, and what arrays do with `=` is to empty themselves and then assign the list of elements on the RHS of the `=` into corresponding `Scalar`s stored in each element of the array. So you end up with two elements. **And the first element is a reference to itself**. > say @r; # (\Array_53270704 = [Array_53270704 d]) > dd @r; # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"]) I get both the `gist` (`say`) and `dd` are weird. But that's because the value is both infinite and recursively so. What else can they to do? One could argue that what they're doing is just about the most useful thing that could be done. > So it *does* push a 'd', but it first mangles the original > contents of the array. It looks like @r[0] now has some sort > of circular pointer back to @r. It's doing exactly what your code told it to do, and the display is doing perhaps the most useful thing that can be done, as affirmed by the fact you've correctly guessed the right way about the circular pointer, but have wrongly guessed that that is a resulting of it "mangling".. > Whatever this "class-dependent" behavior is, I would suggest > it's a "fail". Could this be a bug? It isn't really anything to do with "class dependent" behaviour. Perhaps more importantly, what improvement do you propose? ---- > I was playing around with this a bit and now I'm wondering what > it's talking about with that "class-dependent way". First, to get one suspicion I have out of the way, I suspect it may actually be object dependent. If so, calling it "class dependent" may just be intended to be a helpful simplification, and even if it isn't, I'm going to roll that way and only refer to the dependent aspect as "class dependent", even if it is in reality potentially object dependent. ---- There are two aspects to what happens: * Syntax -- specifically, use of a `$` sigil on the LHS. * Class dependence. Syntax is determined by the compiler, before a class gets to have any say about what to do. So let's deal with syntax first. If the LHS receiver of `=` starts with a `$` sigil then "item assignment" applies. my $foo = 1; $foo = 2,3; # Useless use of ... 3 say $foo; # 2 Note how the *first* value listed on the right is assigned to the variable, but any other values are LOUDLY discarded (i.e. there's a warning message) by the *compiler*: In all other scenarios, "list assignment" applies. The compiler passes *all* the RHS values to the LHS receiver, What then happens depends on the receiver. It's important to be clear that this first aspect is all about the `$` sigil. 42 = 99,100; # "Cannot modify an immutable Int (42)" error No `$` sigil on the LHS so the above is *list assignment*. my \foo = $; foo = 99, 100; say foo; # (99 100) Again, the assignment to `foo` is *list assignment*. Conversely: my $bar := 42; $bar = 99,100; # Both "Useless use of ... 100" warning and "Cannot assign" error There's a `$` sigil on the LHS so the above is *item assignment*. $ = 99,100; # Useless use of constant integer 100 Again, a `$` sigil, so *item assignment* applies. The `$` sigil has to be at the *start* of what is being considered by the compiler: ($,$foo) = 4,5,6; # 4 thrown away explicitly. 6 thrown away silently. say $foo; # 5 ---- If the LHS starts with a `$` then, at runtime, it is given a single value. If it is a `Scalar`, all it does is the metaphoric equivalent of storing that value "inside" the `Scalar` container. This is what it means to "assign to" a `Scalar`. ---- In all other cases the compiler passes *a list of values* at runtime to the receiver. What that receiver does with the list depends on the receiver's class. ---- > that particular pair-input syntax is my least favorite. > Flipping around the order of key and value when the value is a numeric...? > > And it isn't needed to demo the operator, any pair input syntax works. > I might argue that examples should .... I think the docs reflect a desire to show rich examples that go beyond the bare minimum. For some purposes that's a great thing. For others it's a bad thing. If you are willing to put a *great deal* of effort into helping evolve the doc by both patiently discussing your concerns AND also *writing* and/or *rewriting* doc in accord with a mandate to do so based on a rough consensus, where rough doesn't mean unfriendly to any of those involved, then I am 100% with you, and may even be talked into helping a bit. Otherwise, I think that by far the most important thing is that we support folk who both really care about improving the doc and who will keep working on it in a manner that helps sustain progress for both our doc and that of the individuals doing the work. > favor the form that "say" is going to spit back to you. I agree with the sentiment of reducing cognitive load on readers. I'd add a further wrinkle. I love that Larry introduced `gist`s and made `say` use them. I like the fact that gists for things like lists elide commas, string quotes etc. I like that there's `.raku` for when you want the exact Raku syntax that would reproduce some Raku value. In my own examples (not in the doc) I sometimes explicitly use `.raku`. But explicitly adding it can sometimes be just as distracting to a reader as the difference between a .`.gist`/`.say` vs a `.raku`. Another option has occurred to me as I write this email, which is to adopt the principle of using REPL examples in some cases, as against just plain blocks of code, and presuming use of the option Liz added recently to the REPL to pick which method is used to display each response from the REPL, and to make it be `.raku`.
