in reply to Re: undef as an lvalue
in thread undef as an lvalue

What shall we call these? "Ephemeral list elements"? As you know, merlyn, they actually last a little longer then that piece of doc implies. They are not just immediately thrown away. They last long enough for us to grab the value that undef held a place for. Some examples will help here: 
  my @w = () = 1;
  print "[", @w, "]\n";               # prints: []

  my @x = (undef) = 2;
  print "[", @x, "]\n";               # prints: [2]

  my @y = (undef) = (3,4);
  print "[", @y, "]\n";               # prints: [3]

  my @z = (undef, undef) = (5,6);
  print "[", @z, "]\n";               # prints: [56]

  my $temp;
  my @z = (undef, $temp, undef) = (7,8,9);
  print "[", @z, "]\n";               # prints: [789]

[download]
All of which is related to but a bit different from the following which (like the first example above) does not return values-in-a-list but still manages to force a list context for what will be returned by the regex (or any other expression that can return scalar or list). That elusive ghost list can then be construed into a scalar count of the list elements: 
  my $count = () = "abacadaeafag" =~ /a/g;
  my @empty = () = "abacadaeafag" =~ /a/g;
  print "[", $count, "]\n";           # prints: [6]
  print "[", @empty, "]\n";           # prints: []

[download]
Even more ephemeral. But the "$count = () = m//" construct can be handy occasionally.

Update: a friend asked for an example of 'handy'. Herewith offered: 

  $_ = "abacadaeafag";                # or whatever
  if ( scalar( () = /a/g ) > 7 ) {    # more than 7 'hits'?
     # do something...
  }

[download]

Replies are listed 'Best First'.
Re: Re: Re: undef as an lvalue
by chromatic (Archbishop) on Feb 26, 2001 at 02:35 UTC
    Are those *really* lvaluable undefs holding their values, or is it merely Perl ever-so-helpfully evaluating the expression and providing its evaluant (I can't think of the correct computer science word for this at the moment) when evaluating the expression?

    Without looking at the code, I'm 95% sure it's the latter. Why write a special case for what's already a special case?

    To illustrate what I mean, consider using an assignment as a conditional: 

    if (my $y = 1) {
    print "Y!  ($y)\n";
}
print "Y is still ($y)\n";

    [download]
    Scoped as you expect, and behaves as you expect. Using undef as an lvalue within a list is the special case. The fact that that assignment evaluates to what you'd expect with a regular assignment is not.
[reply]
[d/l]
      my @y= (undef)= (3,4);

      [download]

      Since this sets @y to (3) not (3,4) nor (2), I think these are actually modifiably undefs. But that makes perfect sense to me considering subroutine arguments... 

      sub set {
    my( $pos, $newval )= @_;
    $_[$pos]= $newval;
    return $_[$pos];
}
print set( 2, "hello", undef ), $/; # prints "hello"
my $x= "one";
print set( 2, "two", $x ), $/;      # prints "two", changes $x
print $x, $/;                       # prints "two"
print set( 2, "four", $x.3 ), $/;   # prints "for", $x unchanged
print $x, $/;                       # prints "two"
print set( 2, "hello", "goodbye" ); # dies with:
# Modification of a read-only value attempted

      [download]

      When you pass things to a subroutine, @_ usually ends up holding aliases to variables passed in. That is, you can modify the variables by modifying $_[2], for example. But if you pass in an expression, then the subroutine gets a copy instead of an alias.

      In the case of undef, Perl has several choices: 1) It could pass in an alias to the one, read-only undefined value. 2) It could pass in a modifiable copy of the undefined value. 3) It could pass in a read-only copy of the undefined value.

      In our last line of code above, Perl is passing in a alias to the read-only value "goodbye". This makes some sense in that it catches certain coding mistakes. But, since this is Perl, that is probably mostly considered unfortunate, the preference being to be flexible and allow such strange practices for which it is hard to imagine a use (until, of course, you have a use for them). So I think the real reason it does this is to avoid the overhead of copying the possibly large value.

      In the case of undef, I think Perl always passes in a writeable copy because: 1) undef is never large and 2) it can be handy to pass in undef even though the subroutine intends to modify that argument. So undef can be used to mean "I don't care" about that value and the subroutine doesn't have to be coded to check for that case. Very Perlish.

      So when building a list, undef is always copied and so become modifiable. 

      ($a,undef,$b)= @x;    # [undef] is copied
($a,"hi",$b)= @x;     # "hi" is aliased and so this dies
@x= ($a,undef,$b);    # [undef] is copied so $x[1] is modifiable
@x= ($a,"hi",$b);     # "hi" is copied so $x[1] is modifiable

      [download]
              - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
Re: Re: Re: undef as an lvalue
by MeowChow (Vicar) on Feb 26, 2001 at 00:41 UTC
    A minor nit, the scalar in your last example is superfluous, since the numeric comparison forces the LHS into scalar context anyway: 
    $_ = "abacadaeafag";                # or whatever
if ( ( () = /a/g ) > 7 ) {    # more than 7 'hits'?
   # do something...
}

    [download]
       MeowChow                                   
               s aamecha.s a..a\u$&owag.print
[reply]
[d/l]

In Section Seekers of Perl Wisdom