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
| [reply] [d/l] [select] |
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...)
| [reply] [d/l] [select] |
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...
| [reply] [d/l] |
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*...)
| [reply] [d/l] [select] |