in reply to Re: Non-destructive array processing
in thread Non-destructive array processing

Yes, the closure trick is clever, but I don't wonder which is faster. Aside from my assumption that it must be slower due to the function overhead in Perl, the obfuscation factor alone would cause me to eschew it. However, there's a more subtle problem at work that's going to kill many programmers. Since @_ aliases the argument list, the following two lines are equivalent:

my $r1 = sub { \@_ }->(@array);
my $r2 = \@array;

[download]

What that means is that any processing on $r is going to affect @array. The following snippet will clarify.

use Data::Dumper;
my @array = 1..10;
my $aref  = sub {\@_}->(@array);
$_++ foreach @$aref;
print Dumper \@array;
my $r2 = \@array;
print \@array,"\n",$r2;

[download]

The way to get around that with a closure is to do this:

my $r = sub {my @a = @_; \@a}->(@array);

Clearly that's not going to be faster than simply copying the array.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Replies are listed 'Best First'.
Re^3: Non-destructive array processing
by adrianh (Chancellor) on Jan 20, 2003 at 22:51 UTC
    Since @_ aliases the argument list, the following two lines are equivalent: 
    my $r1 = sub { \@_ }->(@array);
my $r2 = \@array;

    [download]

    No they're not :-)

    The first is a reference to an array that has every element aliased to every element of @array.

    The second is a reference to @array.

    The "trick" wouldn't work otherwise, since changing $r2 will change @array. For example.

    my @array = (1..10);
my $r1 = sub { \@_ }->(@array);
pop @$r1;
print "unchanged @array\n";
my $r2 = \@array;
pop @$r2;
print "changed @array\n";

    [download]

    gives us

    unchanged 1 2 3 4 5 6 7 8 9 10
changed 1 2 3 4 5 6 7 8 9

    [download]
[reply]
[d/l]
[select]
      The first is a reference to an array that has every element aliased to every element of @array.

      Very very true. (I was going to say if it wasnt already said...) This has some devious implications. Consider the consequences of this: 

      $\="\n";
my ($x,$y,$z)=(1,2,3);
my $r=sub{ \@_ }->($x,$y,$z,$z,$y,$x);
print $r->[0]; # 1
$r->[-1]=10;
print $r->[0]; # 10

      [download]
      So personally I wouldnt use this approach at all (for this anyway). Theres waaaay too much chance that somebody would come along and morph the code without understanding the deeper implications and then run around screaming about bizarre bugs.

      --- demerphq
      my friends call me, usually because I'm late....

[reply]
[d/l]
Re: Re: Re: Non-destructive array processing
by pdcawley (Hermit) on Jan 20, 2003 at 22:33 UTC
    Heh. I'm so used to slinging objects around rather than simple scalars I just took it as read that it would be a shallow copy. Note that, in the original case that's not a problem because assigning to @chunk makes a copy of the value.
[reply]
[d/l]

      Whoa! You're right. That doesn't seem to be very DWIM. The following snippet does not alter the elements of @array.

      my @array = 1..10;
my $r1 = sub { \@_ }->(@array);

while (my @chunk = splice @$r1, 0, 2) {
   print "Chunk: @chunk\n";
}
$_++ foreach @$r1;
print "Original array is still intact! (@array)\n";

      [download]

      However, by moving the auto-increment line above the while loop:

      my @array = 1..10;
my $r1 = sub { \@_ }->(@array);

$_++ foreach @$r1;
while (my @chunk = splice @$r1, 0, 2) {
   print "Chunk: @chunk\n";
}
print "Original array is not intact! (@array)\n";

      [download]

      This looks like some weird "copy on write" behavior that I was not aware of. Is this new, or is it Yet Another Feature that I didn't know about? :)

      Update: Okay, I see that adrianh answered the question.

      Cheers,
      Ovid

      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
[d/l]
[select]

In Section Meditations