Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Elizabeth Mattijsen]

Fixed with https://github.com/rakudo/rakudo/commit/ae7bcf1b8e , more tests 
needed

> On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  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. 
> # 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.

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Elizabeth Mattijsen]

FWIW, I’m working on a fix

> On 27 Feb 2017, at 17:11, Brandon Allbery  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  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 <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  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 
> > 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 
> >> 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.
> >>> > # 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, xmonadhttp://sinenomine.net
> 
> 
> 
> -- 
> brandon s allbery kf8nh   sine nomine associates
> allber...@gmail.com  ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Brandon Allbery]

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  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 
> > 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 
> >> 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.
> >>> > # 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, xmonadhttp://sinenomine.net

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Brandon Allbery]

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



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Parrot Raiser]

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

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Brandon Allbery]

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 
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 
> 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.
>> > # 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, xmonadhttp://sinenomine.net

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Brandon Allbery]

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  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.
> > # 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, xmonadhttp://sinenomine.net

Re: [perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[Elizabeth Mattijsen]

FWIW, this feels like a DIHWIDT case

> On 27 Feb 2017, at 00:55, Aleks-Daniel Jakimenko-Aleksejev (via RT) 
>  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. 
> # 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.

[perl #130870] Some self-referential issue with hash assignment (%h1 = %h1, %h2)

[via RT]

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