From @AlexDaniel

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd argue that it should work exactly the same way as if it was an assignment to a different hash.

From @lizmat

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd argue that it should work exactly the same way as if it was an assignment to a different hash.

The RT System itself - Status changed from 'new' to 'open'

From @AlexDaniel

Not really. It is a legitimate assumption that if you can compose a new hash like this, then you can use the same syntax to add to existing hash.

In other words, I assumed ｢%h1 ,= %h2｣ to work like ｢%h1.push​: %h2｣.

Or am I missing something?

On 2017-02-27 01​:36​:27, elizabeth wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT)
<perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an
assignment to a different hash.

From @geekosaur

I disagree; this is not Haskell, if I do something like that then I expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl> wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From @geekosaur

And yes, I know that it *is* retaining its value as an object pointer, just
not the contents. But if I write something like that, I pretty clearly mean
the *contents*.

On Mon, Feb 27, 2017 at 10​:46 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

I disagree; this is not Haskell, if I do something like that then I expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl>
wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From 1parrota@gmail.com

I agree with Brandon on this one.

RHS retaining its original value, even when being updated on the LHS
is a fundamental behaviour in Perl. Changing that, especially in
obscure special circumstances would be bad.

On 2/27/17, Brandon Allbery <allbery.b@​gmail.com> wrote​:

And yes, I know that it *is* retaining its value as an object pointer, just
not the contents. But if I write something like that, I pretty clearly mean
the *contents*.

On Mon, Feb 27, 2017 at 10​:46 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

I disagree; this is not Haskell, if I do something like that then I
expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl>
wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an
assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

From @geekosaur

To unpack this a bit​: in this case I understand the comma to be an infix
operator that creates a container by unpacking any containers it encounters
and combining their contents with any non-containers it finds, in the
specified order, to make a new collection of contents. It operates on the
level of contents, not containers. If I want a container to be an item, I'm
fine with itemizing it explicitly.

On Mon, Feb 27, 2017 at 11​:03 AM, Parrot Raiser <1parrota@​gmail.com> wrote​:

I agree with Brandon on this one.

RHS retaining its original value, even when being updated on the LHS
is a fundamental behaviour in Perl. Changing that, especially in
obscure special circumstances would be bad.

On 2/27/17, Brandon Allbery <allbery.b@​gmail.com> wrote​:

And yes, I know that it *is* retaining its value as an object pointer,
just
not the contents. But if I write something like that, I pretty clearly
mean
the *contents*.

On Mon, Feb 27, 2017 at 10​:46 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

I disagree; this is not Haskell, if I do something like that then I
expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl>
wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an
assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From @geekosaur

Or to put this another way​: the current behavior seems like an
overoptimization where it finds the target container in the source and
optimizes into an update. This is only safe if the target is the first
thing in the list of new contents; you must deoptimize in all other
situations (unless your optimizer is *really* clever), and it's on the
programmer to accept the resulting deoptimization and if necessary rewrite
to avoid it.

On Mon, Feb 27, 2017 at 11​:08 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

To unpack this a bit​: in this case I understand the comma to be an infix
operator that creates a container by unpacking any containers it encounters
and combining their contents with any non-containers it finds, in the
specified order, to make a new collection of contents. It operates on the
level of contents, not containers. If I want a container to be an item, I'm
fine with itemizing it explicitly.

On Mon, Feb 27, 2017 at 11​:03 AM, Parrot Raiser <1parrota@​gmail.com>
wrote​:

I agree with Brandon on this one.

RHS retaining its original value, even when being updated on the LHS
is a fundamental behaviour in Perl. Changing that, especially in
obscure special circumstances would be bad.

On 2/27/17, Brandon Allbery <allbery.b@​gmail.com> wrote​:

And yes, I know that it *is* retaining its value as an object pointer,
just
not the contents. But if I write something like that, I pretty clearly
mean
the *contents*.

On Mon, Feb 27, 2017 at 10​:46 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

I disagree; this is not Haskell, if I do something like that then I
expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl>
wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT)
<
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an
assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From @lizmat

FWIW, I’m working on a fix

On 27 Feb 2017, at 17​:11, Brandon Allbery <allbery.b@​gmail.com> wrote​:

Or to put this another way​: the current behavior seems like an overoptimization where it finds the target container in the source and optimizes into an update. This is only safe if the target is the first thing in the list of new contents; you must deoptimize in all other situations (unless your optimizer is *really* clever), and it's on the programmer to accept the resulting deoptimization and if necessary rewrite to avoid it.

On Mon, Feb 27, 2017 at 11​:08 AM, Brandon Allbery <allbery.b@​gmail.com> wrote​:
To unpack this a bit​: in this case I understand the comma to be an infix operator that creates a container by unpacking any containers it encounters and combining their contents with any non-containers it finds, in the specified order, to make a new collection of contents. It operates on the level of contents, not containers. If I want a container to be an item, I'm fine with itemizing it explicitly.

On Mon, Feb 27, 2017 at 11​:03 AM, Parrot Raiser <1parrota@​gmail.com> wrote​:
I agree with Brandon on this one.

RHS retaining its original value, even when being updated on the LHS
is a fundamental behaviour in Perl. Changing that, especially in
obscure special circumstances would be bad.

On 2/27/17, Brandon Allbery <allbery.b@​gmail.com> wrote​:

And yes, I know that it *is* retaining its value as an object pointer, just
not the contents. But if I write something like that, I pretty clearly mean
the *contents*.

On Mon, Feb 27, 2017 at 10​:46 AM, Brandon Allbery <allbery.b@​gmail.com>
wrote​:

I disagree; this is not Haskell, if I do something like that then I
expect
%h2 to retain its original value while the RHS is being evaluated.

On Mon, Feb 27, 2017 at 4​:35 AM, Elizabeth Mattijsen <liz@​dijkmat.nl>
wrote​:

FWIW, this feels like a DIHWIDT case

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <
perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd
argue that it should work exactly the same way as if it was an
assignment
to a different hash.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

From @zoffixznet

On Mon, 27 Feb 2017 07​:49​:13 -0800, allbery.b@​gmail.com wrote​:

But if I write something like that, I pretty clearly mean
the *contents*.

The claimed clarity isn't so clear to me. If we swap hashes for arrays, then you *don't*
mean the contents. You get a self-referential structure​:

  <Zoffix> m​: my @​h1 = 42; my @​h2 = 72; @​h1 = @​h1, @​h2; say @​h1
  <camelia> rakudo-moar 1891b6​: OUTPUT​: «(\Array_56526616 = [Array_56526616 [72]])␤»

I'm surprised you don't get the same with hashes. If you give a comma-separated list of stuff,
it becomes key-value pairs; yet hashes get special treatment in that regard​:

  <Zoffix> m​: my %h1 = :42a; my %h2 = :72a; %h1 = 42, 72, %h2; say %h1
  <camelia> rakudo-moar 1891b6​: OUTPUT​: «{42 => 72, a => 72}␤»

You're forced to use an explicit Pair​:

  <Zoffix> m​: my %h1 = :42a; my %h2 = :72a; %h1 = %h1 => %h2; say %h1
  <camelia> rakudo-moar 1891b6​: OUTPUT​: «{ => {a => 72}}␤»
  <Zoffix> m​: my %h1 := :{​:42a}; my %h2 = :72a; %h1 = %h1 => %h2; say %h1
  <camelia> rakudo-moar 1891b6​: OUTPUT​: «(\Hash_56477024 = {Hash_56477024 => {a => 72}})␤»

So to me the bug is this doesn't happen automatically (and that the first key is empty above)

From @lizmat

Fixed with rakudo/rakudo@ae7bcf1b8e , more tests needed

On 27 Feb 2017, at 00​:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string​: [perl #​130870]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=130870 >

Code​:
my %h1 = <1 a 2 b>;
my %h2 = <3 c 4 d>;
my %h3 = <5 e 6 f>;
%h2 = %h1, %h2, %h3;
say %h2

Result​:
{1 => a, 2 => b, 5 => e, 6 => f}

Notice that it has everything except for elements of %h2.

If this behavior is correct, then it should throw a warning. But I'd argue that it should work exactly the same way as if it was an assignment to a different hash.

From @zoffixznet

Tests added in Raku/roast@3cd5126000

@zoffixznet - Status changed from 'open' to 'resolved'