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 <1parr...@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 <allber...@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 <allber...@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 <l...@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-follo...@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.perl.org/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 > >> allber...@gmail.com > >> ballb...@sinenomine.net > >> unix, openafs, kerberos, infrastructure, xmonad > >> http://sinenomine.net > >> > > > > > > > > -- > > brandon s allbery kf8nh sine nomine > > associates > > allber...@gmail.com > > ballb...@sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > > http://sinenomine.net > > > -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
