LanX has asked for the wisdom of the Perl Monks concerning the following question:

Honorable monks!

(EDIT: for a simplified bug-demo see update further down and one-liner post)

For Re: Syntax explanation required I tried to show the elimination of duplicates when assigning a list of two hashes to a third hash.

But while the third hash holds the correct results (line 105) the return value (line 102) of the assignment looks very weird, and I can't really explain whats happening.

  DB<100> %h1=(a=>1,b=>2);
 => ("a", 1, "b", 2)
 
  DB<101> %h2=(a=>11,c=>3);
 => ("a", 11, "c", 3)
 
  DB<102> %h=(%h1,%h2)
 => ("b", 2, "b", 2, "c", 3)
 
  DB<103> @ret = ( %h=(%h1,%h2) )
 => ("b", 2, "b", 2, "c", 3)
 
  DB<104> \@ret
 => ["b", 2, "b", 2, "c", 3]
 
  DB<105> %h
 => ("c", 3, "a", 11, "b", 2)

[download]

to be sure that it's not just my repl showing buggy results I reproduced it again on the console:

> perl
%h1=(a=>1,b=>2);
%h2=(a=>11,c=>3);
print (%h3=(%h1,%h2),"\n");
 
print %h3;
 
__END__
b2b2c3
c3a11b2

[download]

I'm still suffering from a little hangover from recent tumultuous events ... ;-)

So please could someone tell me what I am missing here?

Cheers Rolf

UPDATE:

I was able to further isolate whats happening to a simple list assignment:

  DB<107> %h=("a", 1, "b", 2, "c", 3, "a", 11)
 => ("b", 2, "b", 2, "c", 3)
 
  DB<108> %h=("a", 1, "b", 2, "c", 3, "d", 4)
 => ("a", 1, "b", 2, "c", 3, "d", 4)
 
  DB<110> %h=("a", 1, "a", 11, "b", 2)
 => ("a", 11, "a", 11)

[download]

seems like that the fact that duplicated keys are eliminated (here a) somehow confuses the returned value.

Replies are listed 'Best First'.
Re: return of assigment in list context (bug?)
by dsheroh (Monsignor) on Jan 02, 2013 at 14:03 UTC
    What version of perl are you using? With my 
    This is perl 5, version 14, subversion 2 (v5.14.2) built for i686-linu
+x-gnu-thread-multi-64int

    [download]
    I get the results that I would expect, with no duplicated values: 
    $ perl
%h1=(a=>1,b=>2);
%h2=(a=>11,c=>3);
print (%h3=(%h1,%h2),"\n");
 
print %h3, "\n";
a11b2c3
c3a11b2

    [download]
[reply]
[d/l]
[select]
      This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

      Thanks a lot... so it's an already fixed bug and I can stop chasing my faults! :)

      Cheers Rolf

[reply]
[d/l]

        It appears to have been fixed between 5.12 and 5.14, though nothing is noted in perl5140delta.

        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
[reply]

      Hi

      Kindly let me know which OS you are using

      Perlpetually Indebted To PerlMonks

      Win 7 at Work. Living through it....Linux at home. Loving it.

[reply]
Re: return of hash-assigment in list context (bug?)
by choroba (Cardinal) on Jan 02, 2013 at 14:06 UTC
    I cannot replicate the bug in 5.14.2 nor 5.17.6. What version are you using?
    لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
[reply]

      I can replicate it with 5.12.4 and 5.10.1, so I'm guessing it got fixed before 5.14

[reply]
Re: return of hash-assigment in list context (bug?)
by Anonymous Monk on Jan 02, 2013 at 21:16 UTC
[reply]
      http://perl5.git.perl.org/perl.git?a=search&h=HEAD&st=free&s=hash+assign
      2012-12-18
Dave RolskyBetter description of hash assignment bug fixes
Better description of hash assignment bug fixes

commit | commitdiff | tree


2012-12-18
Dave RolskyClarify hash assignment bug fix in list context
Clarify hash assignment bug fix in list context

commit | commitdiff | tree


2012-12-11
Father Chrysostomos[Merge] hash assignment fixes and speedup
[Merge] hash assignment fixes and speedup
 ...to left algorithm for not magic hash assignment
>     * in list context hash assignment return keys aliased to RHS

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovrefactor aassign
for array and hash assignment "while (relem <= SP)" loop

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovhash assign in list context should copy key as well
hash assign in list context should copy key... 

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovmake sure hash assignment is proper lvalue
make sure hash assignment is proper lvalue

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovfix issues in hash assignment with odd elements
fix issues in hash assignment with odd elements
3) hash assignment with duplicates and odd elements on

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovtest hash assignment with odd elements for leaks
test hash assignment with odd elements for leaks
 ...is tied and dies on fetch then hash assignment

commit | commitdiff | tree


2012-12-11
Ruslan Zakirovtest "Odd number of elements in hash assignment"
test "Odd number of elements in hash assignment"

commit | commitdiff | tree


2012-09-23
Father ChrysostomosStop hash assignment from leaking on croak
Stop hash assignment from leaking on croak

commit | commitdiff | tree


2012-05-22
Lukas Maidocument behavior of duplicate keys in hash assignment
 ...behavior of duplicate keys in hash assignment

commit | commitdiff | tree


2010-09-11
David Mitchelllist cxt hash assign with dups gives garbage
list cxt hash assign with dups gives garbage

commit | commitdiff | tree

      [download]
[reply]
[d/l]
        Thx, this one looks good! =)

        2010-09-11 David Mitchell
        list cxt hash assign with dups gives garbage

        the others are too new.

        Fix for #31865: weird results from reverse( %x = reverse %h )

        Basically, anything of the form

        @a = %h = (list with some duplicate keys)

        may have left @a containing weird and/or freed values.

        There was a partial fix for this with ca65944e, but it was broken (it did one big block move on the stack at the end to remove duplicates, but duplicates weren't necessarily all in one block.)

        The new fix is a two-stage process. First, while pulling key/value pairs of the stack and assigning them to the hash, each key/val pair is written back to the stack - possibly at a lower position if there are duplicates to be skipped.

        Finally at the end if any duplicates have been detected, then in list context, a single pass is made through the stack, and for each key/val pair, the key is looked up and the val on the stack is overwritten with the new value (replacing possibly freed or other garbage values).

        Cheers Rolf

[reply]
Re: return of hash-assigment in list context (bug?)
by karlgoethebier (Abbot) on Jan 02, 2013 at 17:19 UTC
    "I'm still suffering from a little hangover from recent tumultuous events ..."

    Hold on. Lent is coming soon. Perhaps the abbot can recommend some exercises for you?

    Best regards, Karl

    «The Crux of the Biscuit is the Apostrophe»

[reply]

Back to Seekers of Perl Wisdom