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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> >> >> wrote: >> >> >> >>> FWIW, this feels like a DIHWIDT case >> >>> >> >>> > On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) >> < >> >>> [email protected]> 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 >> >> [email protected] >> >> [email protected] >> >> unix, openafs, kerberos, infrastructure, xmonad >> >> http://sinenomine.net >> >> >> > >> > >> > >> > -- >> > brandon s allbery kf8nh sine nomine >> > associates >> > [email protected] >> > [email protected] >> > unix, openafs, kerberos, infrastructure, xmonad >> > http://sinenomine.net >> > >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > [email protected] > [email protected] > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
