in reply to Understanding Perl context

The code shows two approaches to remove duplicates in @array .

The first @unordered approach is using a hash slice, and since hash keys are unique, duplicates are overwritten. But the original order is lost, since keys returns in random order.

The second @ordered approach rejects duplicates from copying, hence @ordered preserves the order of the first occurrences. This is done with %seen which postincrements the value per element

if(  not $seen{$element}++ )

Only 0 is false, hence repeated (i.e. "unseen") elements are filtered out.

PS: As a side note:

A hash slice initializing undef values is better written as @unordered{@array}=() , assigning undef to the first element is misleading!

Cheers Rolf
(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!

Replies are listed 'Best First'.
Re^2: Understanding Perl context (removing duplicates from array)
by AnomalousMonk (Archbishop) on Apr 19, 2015 at 13:17 UTC
    A hash slice initializing undef values is better written as @unordered{@array}=() , assigning undef to the first element is misleading! [emphasis added]

    IMHO, this statement is itself a bit misleading. The two forms of the statement are exactly equivalent! The effect of either  () or  undef as the RHS of the assignment is exactly the same because both are equivalent to lists of  undef values of exactly the same length as the  @array array. This slightly obscure point must be understood regardless of the assignment used, and neither assignment seems to me better suited to making this point.

    Give a man a fish:  <%-(-(-(-<

[reply]
[d/l]
[select]
      Its misleading, because the next maintainer might think he can replace undef with 0 and bang!

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

[reply]

        Hmmm... Hadn't thought about that.

        But in the specific case of the OPed code, replacing  undef with 0 (or, indeed, with 1 or any other value) would make no difference: you still end up with a hash of unique keys.

        And in the general case, if code did depend on the difference between  undef and 0 as values, would not this dependence be underscored by the explicit use of  undef as the initializer (reinforced, one would hope, by a comment) rather than the more general  () empty list?

        Give a man a fish:  <%-(-(-(-<

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom