From @AlexDaniel

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = @​a, @​b;
say @​c

Result​:
[[a b c] [1 2 3]]

So with arrays, nothing is flattened and you get an array with two elements. Makes sense.

And if we want to get a different behavior, we can use slip​:

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = |@​a, |@​b;
say @​c

Result​:
[a b c 1 2 3]

Everything is fine so far. Now, let's try the same thing with hashes​:

Code​:
my %a = <a b c d>;
my %b = <1 2 3 4>;
my %c = %a, %b;
say %c

Result​:
{1 => 2, 3 => 4, a => b, c => d}

To me that looks like an inconsistency, I would have expected it to create a hash with one pair (%a => %b). In fact, both ｢%c = %a, %b｣ and ｢%c = |%a, |%b｣ work exactly the same!

The idea of %a => %b may seem weird, but it really isn't if you consider object hashes (my %c{Hash} = %a => %b; or even my %c{Hash} = $%a, $%b)

Another thing to note is that this array behavior was changed during the GLR, but hashes remained the same. Perhaps that was an oversight.

From @geekosaur

IIRC this hash behavior is deliberate so that hashes can be accumulated.
Also, your proposed behavior would require an object hash, not a standard
hash; (%a => %b) would necessarily stringify %a.

On Thu, Apr 6, 2017 at 4​:46 PM, Aleks-Daniel Jakimenko-Aleksejev <
perl6-bugs-followup@​perl.org> wrote​:

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

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = @​a, @​b;
say @​c

Result​:
[[a b c] [1 2 3]]

So with arrays, nothing is flattened and you get an array with two
elements. Makes sense.

And if we want to get a different behavior, we can use slip​:

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = |@​a, |@​b;
say @​c

Result​:
[a b c 1 2 3]

Everything is fine so far. Now, let's try the same thing with hashes​:

Code​:
my %a = <a b c d>;
my %b = <1 2 3 4>;
my %c = %a, %b;
say %c

Result​:
{1 => 2, 3 => 4, a => b, c => d}

To me that looks like an inconsistency, I would have expected it to create
a hash with one pair (%a => %b). In fact, both ｢%c = %a, %b｣ and ｢%c = |%a,
|%b｣ work exactly the same!

The idea of %a => %b may seem weird, but it really isn't if you consider
object hashes (my %c{Hash} = %a => %b; or even my %c{Hash} = $%a, $%b)

Another thing to note is that this array behavior was changed during the
GLR, but hashes remained the same. Perhaps that was an oversight.

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

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

From @zoffixznet

On Thu, 06 Apr 2017 13​:46​:00 -0700, alex.jakimenko@​gmail.com wrote​:

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = @​a, @​b;
say @​c

Result​:
[[a b c] [1 2 3]]

So with arrays, nothing is flattened and you get an array with two
elements. Makes sense.

And if we want to get a different behavior, we can use slip​:

Code​:
my @​a = <a b c>;
my @​b = <1 2 3>;
my @​c = |@​a, |@​b;
say @​c

Result​:
[a b c 1 2 3]

Everything is fine so far. Now, let's try the same thing with hashes​:

Code​:
my %a = <a b c d>;
my %b = <1 2 3 4>;
my %c = %a, %b;
say %c

Result​:
{1 => 2, 3 => 4, a => b, c => d}

To me that looks like an inconsistency, I would have expected it to
create a hash with one pair (%a => %b). In fact, both ｢%c = %a, %b｣
and ｢%c = |%a, |%b｣ work exactly the same!

The idea of %a => %b may seem weird, but it really isn't if you
consider object hashes (my %c{Hash} = %a => %b; or even my %c{Hash} =
$%a, $%b)

Another thing to note is that this array behavior was changed during
the GLR, but hashes remained the same. Perhaps that was an oversight.

The overwhelming majority of usecases would want merged hashes, not a hash keyed on another hash.

Also, there is consistency with Pairs​:

  m​: my %h = :2a, :3a; dd %h
  <camelia> rakudo-moar 605e9e​: OUTPUT​: «Hash %h = {​:a(3)}␤»

Why would `Hash, Hash` end up as keyed on a Hash, when `Pair, Pair` gets merged?

This parallel is much closer than the Array one, so I'd argue it overrules the inconsistency with more distant types.

From @jnthn

On Thu, 06 Apr 2017 13​:46​:00 -0700, alex.jakimenko@​gmail.com wrote​:

Another thing to note is that this array behavior was changed during
the GLR, but hashes remained the same. Perhaps that was an oversight.

I certainly considered this matter during the course of the GLR, and felt that trying to make the two assignment cases behave the same would count as a foolish consistency. And it's not like there wasn't already precedent for assignment to vary in its rules by sigil. After all, list and item assignment parse at difference precedence levels - which is arguably a much bigger difference than a different choice over flattening!

In fact, it's pretty consistent throughout Perl 6 that you need to know about the target of an assignment in order to know what it's going to do with the source. Assignment into a List like `($a, $b) = @​c` will happily discard unused values, while assignment into a fixed size array will complain if there's too many items. If it's a multi-dimensional array then it will look for the shape to be replicated in the source, and complain if it's not "close enough" (so that's another case where a nested structure on the right will get special treatment). So even within list-space, we have differing assignment semantics based upon the target.

/jnthn

From @coke

On Fri, 07 Apr 2017 06​:07​:58 -0700, jnthn@​jnthn.net wrote​:

On Thu, 06 Apr 2017 13​:46​:00 -0700, alex.jakimenko@​gmail.com wrote​:

Another thing to note is that this array behavior was changed during
the GLR, but hashes remained the same. Perhaps that was an oversight.

I certainly considered this matter during the course of the GLR, and
felt that trying to make the two assignment cases behave the same
would count as a foolish consistency. And it's not like there wasn't
already precedent for assignment to vary in its rules by sigil. After
all, list and item assignment parse at difference precedence levels -
which is arguably a much bigger difference than a different choice
over flattening!

In fact, it's pretty consistent throughout Perl 6 that you need to
know about the target of an assignment in order to know what it's
going to do with the source. Assignment into a List like `($a, $b) =
@​c` will happily discard unused values, while assignment into a fixed
size array will complain if there's too many items. If it's a multi-
dimensional array then it will look for the shape to be replicated in
the source, and complain if it's not "close enough" (so that's another
case where a nested structure on the right will get special
treatment). So even within list-space, we have differing assignment
semantics based upon the target.

/jnthn

Based on jnthn's comment here, rejecting the ticket.

--
Will "Coke" Coleda

@coke - Status changed from 'open' to 'rejected'