develooper Front page | perl.perl6.users | Postings from November 2020

Re: The ,= operator

Thread Previous | Thread Next
Ralph Mellor
November 27, 2020 17:43
Re: The ,= operator
Message ID:
@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*.


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

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About