|
in reply to Autovivification of scalars in sub calls
Arguments to subs are lvalues, and lvalues autovivify. Feature.
Incidentally, you can also induce lvalue context by taking a reference. Interestingly, this program generates a warning about Useless use of reference constructor, but without taking the reference, it dies on the undefined value.
use warnings;
use strict;
my $x;
\@$x;
print @$x;
It should go without saying that using these side-effects to initialize is not a good programming practice.
Caution: Contents may have been coded under pressure.
|
Re^2: Autovivification of scalars in sub calls
by tlm (Prior) on Dec 08, 2005 at 18:34 UTC
|
Interesting. I knew that some builtins, like pos and keys, can be lvalues, but not that arguments to subs were. Come to think of it, I can't even say that I know what the expression "arguments to subs are lvalues" means. How is the argument in sleep( 3 ) an lvalue?
Be that as it may, where can I learn more about this sub-args-as-lvalues thing? I can't find documentation for it.
I agree that it is nice that being in an "lvalue context" induces autovivification, but I don't see the utility of regarding the arguments to a subroutine as lvalues. Granted, in some cases, like substr, the first argument can be thought of as being in an "lvalue context". Sort of. After a few drinks. But this seems too special a situation to warrant turning the arguments to a function into an "lvalue context".
| [reply] |
|
|
use warnings;
use strict;
my $x;
# @$x; # This will die if uncommented
for my $foo (@$x) {
print "Gar!\n";
}
While I'm certain that I read about the @_ lvalues phenomenon here on PM, I haven't been able to Super Search it up. tye mentions it in Re^5: Warnings not being thrown with DBI (nits).
Caution: Contents may have been coded under pressure.
| [reply]
[d/l]
[select] |
|
|
Interesting. I knew that some builtins, like pos and keys, can be lvalues, but not that arguments to subs were. Come to think of it, I can't even say that I know what the expression "arguments to subs are lvalues" means. How is the argument in sleep( 3 ) an lvalue?
Arguments to subs can be assigned to; they're lvalues in that sense.
Therefore, you get these ugly situations:
my $var=3;
mysleep($var); # these two lines are fine
mysleep(3); # but this one causes an error!!!
sub mysleep {
sleep($_[0]);
$_[0]=10;
}
Or this ugly situation...:
$y=substr("hello",10,1);
foo($y);# this runs, but substr() generates warnings because the subst
+r() is outside the string
foo( substr("hello",10,1) ); # this is a fatal error!
Why is it a fatal error? Well, because an invalid substr() is used in a lvalue context. Why is it an lvalue context? Because the subroutine *could* modify the value, and perl isn't smart enough to check to see if it does or not! Worse yet, substr() fails silently on such a fatal error, after generating the *same* warning that's nonfatal in a non-lvalue context. ***SIGH***
I've made it my policy to avoid lvalues() where possible, especially after that substr() issue killed our production code, and wasted a few hours of my time!
--
Ytrew Q. Uiop | [reply]
[d/l]
[select] |
|
|
Perhaps also interesting is that lvalues remain lvalues even after passing them to the unary + operator.
sub foo {}
#foo(substr "hello", 10, 1); # fatal error as you pointed out
#foo(+substr "hello", 10, 1); # I thought this would be a workaro
+und
foo(scalar substr "hello", 10, 1); # but you need something like this
print "This only gets printed if the last line didn't cause a fatal er
+ror\n";
And testing to make sure:
perl -e '+$a = "Hello, world!\n"; print $a'
Hello, world!
(I know it's documented that + does absolutely nothing, and I guess that does mean it doesn't convert lvalues to rvalues, but it's still somewhat surprising to me.) | [reply]
[d/l]
[select] |
|
|
sleep is not a sub. sleep is a buildin. In this, it makes all the difference. Subs have @_, and their arguments are aliased to it. Hence the lvalue of arguments to subs - but not to buildins (with a few exceptions).
Be that as it may, where can I learn more about this sub-args-as-lvalues thing? I can't find documentation for it.
Very early in man perlsub, as soon as it starts talking about @_. The third paragraph of the description:
Any arguments passed in show up in the array @_. There
fore, if you called a function with two arguments, those
would be stored in $_[0] and $_[1]. The array @_ is a
local array, but its elements are aliases for the actual
scalar parameters. In particular, if an element $_[0] is
updated, the corresponding argument is updated (or an
error occurs if it is not updatable). If an argument is
an array or hash element which did not exist when the
function was called, that element is created only when
(and if) it is modified or a reference to it is taken.
(Some earlier versions of Perl created the element whether
or not the element was assigned to.) Assigning to the
whole array @_ removes that aliasing, and does not update
any arguments.
| [reply]
[d/l] |
Re^2: Autovivification of scalars in sub calls
by ambrus (Abbot) on Mar 23, 2007 at 14:31 UTC
|
| [reply]
[d/l] |
|
|
