No autovivification, for loop aliasing, #15583
Comments
From @leszekdubielCreated by @leszekdubielThis is after the discussion here: http://www.perlmonks.org/?node_id=1171041 Data structure: my $n = { This throws exception: @{$$n{'x'}}; And this doesn't: for my Maybe it is somehow connected with autovivification. Here is program: #!/usr/bin/perl -CSDA use utf8; print "\n\ninitialize data structures, no autovivification\n"; # "Can't use an undefined value as an ARRAY reference": print "\n\nnow the same but in loop:\n"; print "\n\nnow the same but in loop:\n"; Perl Info |
From @jkeenanOn Fri Sep 02 13:54:24 2016, leszek@dubiel.pl wrote:
Perhaps it does -- but since you are referencing the 'autovivification' module from CPAN (http://search.cpan.org/~vpit/autovivification-0.16/lib/autovivification.pm#BUGS), you first have to rule out the possibility that this is a bug in that library. Reports sent to rt.perl.org should be concerned only with the Perl 5 core distribution. The 'autovivification' library is not part of the core distribution. Please report this problem first to the CPAN maintainer of 'autovivification' via sending mail to: bug-autovivification [at] rt.cpan.org If the discussion there discloses a bug in the Perl 5 core distribution, then we can open a new ticket here or re-open this one.
Note for when you report this problem at rt.cpan.org: Much of what you have above is superfluous for the purpose of filing a bug report. You can and should eliminate the '-CSDA'; the 'use utf8'; and the 'no warnings qw{uninitialized numeric}'. Strip down the code sample to the minimum code that reproduces the problematic behavior.
Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
|
@jkeenan - Status changed from 'open' to 'rejected' |
From @leszekdubielHello! Here's striped down version. #!/usr/bin/perl use strict; my $n = {}; # this is ok... # the same throws exception: |
From @jkeenanOn Sat Sep 03 15:00:21 2016, leszek@dubiel.pl wrote:
Yes, for the purpose of discussing autovivification in general (as distinct from the 'autovivification' pragma on CPAN), this is a better code sample. The documentation of autovivification in the core distribution is clearly less than satisfactory. By consulting four different doc files (as well as the CPAN autovivification documentation), have pieced together the following explanation which should be treated as a *provisional, layperson's* explanation of the phenomenon. The documentation is somewhat adequate in explaining why array and hash elements autovivify when they do, but -- as you have probably found out already -- quite inadequate in explaining why autovivification does *not* happen where you might expect it to. So here goes. Perl autovivifies intermediate elements in data structures when it senses that you need to use the lowest elements in such structures as *storage locations*. In Perl, a storage location is referred to as an *lvalue* (where the 'l' refers to the customary 'left-hand side' or an assignment). The context in which you are assigning a value to a storage location -- or when Perl senses that you are about to assign a value to a storage location -- is referred to as *lvalue context*. When you need to assign a value to an array or hash element that doesn't already exist, Perl will create that elements -- and any elements needed to reach that element -- for you. More formally, when you are in lvalue context, perl will autovivify data structures as needed.
In the above you are (IMO) in lvalue context. You are saying, "For each element of the array which is the value of a hash element whose key is 'x' -- and where said hash is dereferenced from $n -- I am going to do something which may (or may not) include storing an element in that array. I need that array to exist even if it does not yet have any elements." Let me slightly rewrite what we've got so far in a more contemporary notation: ##### Output: #####
Here, I would argue, you are *not* in lvalue context. You're not indicating any current or future need to store values in the array which is the value of a hash keyed on 'y'. In fact, if we were to set aside the runtime exception and simply look at the code, we'd probably say, "We're in scalar context; we're asking whether we have a Perl-true (non-zero) number of elements in that array and, if so, we are printing a numeral." Since we're not in lvalue context, there's no call for autovivification of the array, which (I think) renders the array reference undefined. Here, too, we can update the syntax without changing the problem: ##### That triggers the exception you have encountered. But this exception is to be expected.
We don't really know the real-world context if which you encountering this problem. However, if at this point, what you want to do is to create an array -- initially empty but intended for later storage of values -- and you want that array to be the value of a hash keyed on 'y' in a hash referenced from $n, then you could say: ##### Together with the 'x' code above, this would now output: ##### HTH References in core distribution: cpan/perlfaq/lib/perlfaq4.pod P5P: We need to work a discussion like the above into our documentation of autovivification. Patches welcome! Thank you very much. -- |
From @jkeenanOn Sat Sep 03 17:26:00 2016, jkeenan wrote:
Follow-up: Vincent Pit pointed on irc.perl.org #p5p that this exception is a consequence of your (correct) use of 'use strict;'. -- |
From @cpansproutThe possibility of making foreach refrain from autovivification when possible has been raised before (i.e., it would be considered a bug fix), but it has been put off indefinitely because it would cause a significant slowdown. -- Father Chrysostomos |
From @ap* Father Chrysostomos via RT <perlbug-followup@perl.org> [2016-09-04 04:12]:
It’s not just speed. The semantics are serious headache too. Referential The bug that *could* be fixed is autovivification in *rvalue* context. But not lvalue context; that would be way too much of a braintwister. Regards, |
Migrated from rt.perl.org#129177 (status was 'rejected')
Searchable as RT129177$
The text was updated successfully, but these errors were encountered: