Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Autovivification of scalars in sub calls

by tlm (Prior)
on Dec 08, 2005 at 01:11 UTC ( #515098=perlmeditation: print w/ replies, xml ) Need Help??

Dear monks,

One interesting way to live up to the principle of least surprise is to shock your users so frequently and so thoroughly that soon nothing will surprise them anymore. I'm there.

Watch:

% perl -Mstrict -le 'my $x; my @y = @$x; print "=> ", ref $x' Can't use an undefined value as an ARRAY reference at -e line 1. % perl -Mstrict -le 'my $x; sub {}->( @$x ); my @y = @$x; print "=> ", + ref $x' => ARRAY

The useless subroutine call sub {}->( @$x ) autovivifies @$x. Incidentally, builtin functions do not provide a similar service:

% perl -Mstrict -le 'my $x; scalar( @$x ); my @y = @$x; print "=> ", r +ef $x' Can't use an undefined value as an ARRAY reference at -e line 1.

Bug? Feature? You decide.

I'm sure that more erudite monks will be able to scrape up the documentation for this bugeature from some recondite corner of the Perl docs, but an innocent grep for "autoviv" in perlsub left me none the wiser.

Cheers.

Update: Fixed the ill-chosen example of qw(...) as "builtin function". Thanks to japhy for pointing out the gaffe.

the lowliest monk

Comment on Autovivification of scalars in sub calls
Select or Download Code
Re: Autovivification of scalars in sub calls
by japhy (Canon) on Dec 08, 2005 at 01:14 UTC
    Um, qw( @$x ) is not a "builtin function". It's the single quoted string '@$x'.

    Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
    How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart
      True, although an example with print demonstrates the behavior to which tlm was referring:

      perl -Mstrict -le 'my $x; print @$x' Can't use an undefined value as an ARRAY reference at -e line 1. perl -Mstrict -le 'my $x; sub { }->( @$x ); print @$x' (No error generated)
Re: Autovivification of scalars in sub calls
by Tanktalus (Canon) on Dec 08, 2005 at 05:12 UTC

    To be honest, the only places I rely on autovivication are: hash values, array values, and anywhere explicitly documented to use autovivication (e.g., IPC::Open3), although in that last case, I got bit where it promised autovivication and didn't deliver, so I manually "vivified" the handles before passing them in.

    Top-level references, for some reason, I just never tried to use autovivication. I'm not sure why.

    Anyway, we already know that builtins are treated special in many ways - this just seems to be another one. I'm sure we could do something similar with XS somehow .. but I'm not an XS expert. I think perl6 solves this difference making builtins behave the same way as user-defined functions, or, more to the point, allowing user-defined functions to gain builtin-like semantics.

    In your case, the user-defined function autovivifies the array to figure out what @_ will contain. Why perl doesn't need to do likewise for builtins, I'm not sure. Or why perl doesn't figure out that $x being undef will autovivify to an empty list and just skip the autovivication, I'm not sure.

    Note that builtins that treat the array as an lvalue (like using '@' in a prototype) do autovivify:

    $ perl -Mstrict -le 'my $x; push(@$x,"z"); print "=> ", ref $x, $/' => ARRAY
    so it's not all builtins. But it does seem to be all user-defined functions - or at least I've not found a counter example.

Re: Autovivification of scalars in sub calls
by ambrus (Abbot) on Dec 08, 2005 at 09:07 UTC
    Incidentally, builtin functions do not provide a similar service:

    Some builtin functions do. scalar (your example) doesn't, as it never changes its arguments. However, grep does which caused a strange bug for me once: Aliasing bites.

Re: Autovivification of scalars in sub calls
by Roy Johnson (Monsignor) on Dec 08, 2005 at 14:32 UTC
    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.

      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".

      the lowliest monk

        How is the argument in sleep( 3 ) an lvalue?
        In much the same way that \3 is. Not a very good answer, I know, but it's the best I can do. Perl makes @_ an array of aliases to the arguments, as you know. That's much like taking a reference: it requires Perl to consider the arguments in an lvalue context. That aliasing may not happen on builtin functions like sleep, though.

        Another example of aliasing is a for loop. It also provides an lvalue context:

        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.
        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

        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.
        Perl --((8:>*

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://515098]
Approved by ysth
Front-paged by Roy Johnson
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (10)
As of 2014-09-17 17:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (92 votes), past polls