in reply to weird error message in middle-aged-perl(5.14)

From perl5160delta#Lvalue-subroutines (second bullet point):

Lvalue subroutines used to enforce lvalue syntax (i.e., whatever can go on the left-hand side of =) for the last statement and the arguments to return. Since lvalue subroutines are not always called in lvalue context, this restriction has been lifted.

The “last statement” immediately before line 108 is:

if ($rfv eq ARRAY ) { if (defined($wa)) { # arrays special $wa? @{$p->{$vn}} : $addrof ? \$p->{$vn} : $p->{$vn} } } elsif ($rfv eq HASH ) { $p->{$vn} } elsif ($addrof) { return $p->{$vn} } else { return $p->{$vn} }

In the case where $rfv does equal ARRAY but $wa is not defined, this “last statement” does nothing, so the sub will return undef, which is not a valid lvalue.

That’s just my guess as to what is going on. I don’t know where the && in the error message is coming from, but I note that a similar message was reported in http://www.perladvent.org/2005/21/. I can’t experiment as I don’t have version 5.14 installed.

Hope that helps,

Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^2: weird error message in middle-aged-perl(5.14)
by tobyink (Canon) on May 09, 2014 at 10:34 UTC

    Good answer! Allow me to supply the missing puzzle piece.

    "That’s just my guess as to what is going on. I don’t know where the && in the error message is coming from"

    The following two statements are logically equivalent:

    # logical and foo() && bar(); # postfix if bar() if foo();

    The Perl parser in fact compiles them to the same optree. You can see this by running the following commands:

    $ perl -MO=Concise -E'foo() && bar();' $ perl -MO=Concise -E'bar() if foo();'

    After Perl has finished parsing the statement and has built its optree, it "forgets" the code which it originally saw. When it needs to generate an error message, it has to take a guess at whether the error message should talk about "if", "&&", or indeed "and" — in this case, it's gotten it wrong.

    Linda doesn't have any "&&" operators in her code, but she does use the postfix "if" in some places, and it's this which is being complained about by Perl.

    As an aside, for a much easier way of writing lvalue subs, take a look at LV.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re^2: weird error message in middle-aged-perl(5.14)
by AnomalousMonk (Archbishop) on May 09, 2014 at 03:11 UTC

    Running the following program under ActiveState 5.8.9 and Strawberries 5.10/12/14 (all Win32) gives me identical results:

    c:\@Work\Perl>perl -wMstrict -le "my $x = 0; my $y; ;; sub S :lvalue { if ($x) { $y; } } ;; S() = 'foo'; ;; print qq{x '$x' y '$y'}; " Can't modify logical and (&&) in lvalue subroutine return at -e line 1 +, near "} }" Execution of -e aborted due to compilation errors.

    Given the experimental nature of  :lvalue trumpeted in the Lvalue subroutines section of perlsub, I would be very reluctant to use it with a complex subroutine. If the Perl compiler can't even figure out the simple example code above, what hope for the vipers' nest of conditionals that is the  _Var() workhorse?

    (Somewhere in the back of my mind is something about the compiler sometimes optimizing a statement like
        if ($x) { do_this(); };
    to
        $x && do_this();
    so this may be part of the problem — but don't quote me on this!

    Update: Actually, it's  $y if $x; that is so optimized/compiled, using and not &&. Nevermind...)

      Given the experimental nature of :lvalue trumpeted in the Lvalue subroutines section of perlsub, I would be very reluctant to use it with a complex subroutine. If the Perl compiler can't even figure out the simple example code above, what hope for the vipers' nest of conditionals that is the _Var() workhorse?
      Point taken -- but to it's credit, _Var was around for a few years BEFORE I added lvalue... i.e. I'd use it:
      ...(skipping prologue) my $p=main->SUPER::new({scalar=>1, arr=>[1,2,3,4], hsh=>{one=>1, two=>2, three=>3}}); #w/o lvalue: $p->scalar($p->scalar+1); $p->arr(1,22); $p->arr(3,$p->arr(3)+$p->arr(1)); $p->hsh("two",22); $p->hsh("total", $p->hsh("one")+$p->hsh("two")); P "arr=%s", [$p->arr]; P "hsh=%s", $p->hsh; Vs. w/lvalue: $p=$p->SUPER::new({arr=>[1,2,3,4], hsh=>{one=>1, two=>2, three=>3}}); ++$p->value; #or ($p->value++;) $p->arr(1) = 22; $p->arr(3) += $p->arr(1); $p->hsh("two") = 22; $p->hsh("total") = $p->hsh("one")+$p->hsh("two"); P "arr=%s", [$p->arr]; P "hsh=%s", $p->hsh; #both give same results: arr=[1, 22, 3, 26] hsh={one=>1, three=>3, total=>23, two=>22} arr=[1, 22, 3, 26] hsh={one=>1, three=>3, total=>23, two=>22}
      For data that doesn't need runtime checking -- just dynamic allocation in a structure, the lvalue'd versions work great and are considerably less visual 'mess' to use, BUT, as you mention, experimental means semi-worthless for production code. As it is, I tend toward using the non-lvalue form in about 2/3rd of new *assignments*. But when you do a read-modify-write, the lvalue form is awfully tempting.

      Gonna go poke at the return vals as suggested by Athanasius and see if that clears up the error...

Re^2: weird error message in middle-aged-perl(5.14)
by perl-diddler (Chaplain) on May 09, 2014 at 06:15 UTC
    Well.. not exactly it, but put me on track to finding it.

    It didn't like the "\$p->{$vn}".

    Once I fixed that, the error kicked up to the calling routine, which "was":

    sub _access_maker { #{{{ my $pkg = shift; #var in $_ { my $proc = '# line ' . __LINE__ . ' "' . __FILE__ . "\"\n" . ' { use warnings;use strict; package '.$pkg.'; sub '.$_.' (;$) :lvalue { unshift @_, [shift, Data::Vars::varname((caller 0)[3]), want +array]; goto &Data::Vars::_Var}; 1}'; eval $proc; $@ and die "Fatal error in $pkg\::Vars\::_access_maker?: $@\n"; } } ## end sub _access_maker }}}
    It didn't like the 'goto'. So... just a bit of uglification:
    sub _access_maker { #{{{ my $pkg = shift; #var in $_ { my $proc = '# line ' . __LINE__ . ' "' . __FILE__ . "\"\n" . ' { use warnings;use strict; package '.$pkg.'; sub '.$_.' (;$) :lvalue { ' . ($] >= 5.016 ? ' unshift @_, [shift, Data::Vars::varname((caller 0)[3]), want +array]; goto &Data::Vars::_Var ' : ' &Data::Vars::_Var( [shift, Data::Vars::varname((caller 0)[3]), wantarray], +@_); ') .'}; 1}'; eval $proc; $@ and die "Fatal error in $pkg\::Vars\::_access_maker?: $@\n"; } } ## end sub _access_maker }}}
    Ug...Talk about chaotic changes!.... Gonna have to do a bit more testing with this mess of changes...ARG!!!!!!

    Thanks!...(I think...*ouch*...)