"Can't return a temporary from lvalue subroutine..."

[Anno Siegel]

Also sprach J Krugman:


Your post here added enough momentum.

The problem was indeed as I described in
<[email protected]>.
I submitted a patch for it which got applied roughly eight minutes ago.
Applied means it's now in the development branch 5.9.x. But I assume it
will also be in 5.8.8 whenever it's due at which point you can start to
make use of it to your heart's desire.

[clap, clap, clap, bravo]

Open software in action. Can't beat it.

Anno

 

[J Krugman]

The problem was indeed as I described in
<[email protected]>.
I submitted a patch for it which got applied roughly eight minutes ago.
Applied means it's now in the development branch 5.9.x. But I assume it
will also be in 5.8.8 whenever it's due at which point you can start to
make use of it to your heart's desire.

Awesome! Thank you!

j

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Brian McCauley

There are bugs in Perl. In particular if the reference returned by the
%{} overload is the only reference to the tied hash some very nasty
things happen very soon. Even if it's not, nasty things seem to happen
after a while.

Could you be more specific?

Thanks,
Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Anno Siegel

It looks like "temporary" refers to the state of a scalar of being
"mortal". Mortal SVs are all over the Perl source, but normally
only concern XS programmers. This is the first time I see the
distinction appear at Perl level.

There is no way to determine that a thing is mortal (short of walking
up the mortalization stack and checking whether a value is there).
So, obviously, it is not that. Here "a temporary" is an intermediate
variable created by Perl without a direct intervention of a programmer.

I'm afraid that it was me who put this error message there; so all the
blame on its wording may be on me. When I introduced the lvalue subs,
there was a lot of suspicion on p5p that the whole idea is junk; as a
result, the handling is over-protecting. This "can't" in the message,
for example, is red herring; there would be no problem for Perl to
change a value of a temporary; it is just that usually it is not what
a programmer wants:

sub add5 : lvalue {
my $x = shift;
return $x + 5;
}

So the main usage of this message is to warn the programmer of
*possibly* flaky code.

The problem is that the current implementation of tied hashes is using
a temporary to handle access to a value for a key. I did not realize
this when implementing the lvalue subs, so there is no special case to
handle this "legitimate" use of temporaries in lvalue subs.

Hope this helps,
Ilya

 

[Anno Siegel]

[A complimentary Cc of this posting was sent to
Anno Siegel

It looks like "temporary" refers to the state of a scalar of being
"mortal". Mortal SVs are all over the Perl source, but normally
only concern XS programmers. This is the first time I see the
distinction appear at Perl level.

There is no way to determine that a thing is mortal (short of walking
up the mortalization stack and checking whether a value is there).

Oh. I thought of it as some kind of flag in the SV. Tassilo had already
hinted as much. Obviously a little knowledge is a dangerous thing.
Apologies for posting a mere guess.

So, obviously, it is not that. Here "a temporary" is an intermediate
variable created by Perl without a direct intervention of a programmer.

I'm afraid that it was me who put this error message there; so all the
blame on its wording may be on me. When I introduced the lvalue subs,
there was a lot of suspicion on p5p that the whole idea is junk; as a
result, the handling is over-protecting. This "can't" in the message,
for example, is red herring; there would be no problem for Perl to
change a value of a temporary; it is just that usually it is not what
a programmer wants:

sub add5 : lvalue {
my $x = shift;
return $x + 5;
}

Ah, but that it apparently caught in a different place:

Can't modify addition (+) in lvalue subroutine return at ...

So the main usage of this message is to warn the programmer of
*possibly* flaky code.

The problem is that the current implementation of tied hashes is using
a temporary to handle access to a value for a key. I did not realize
this when implementing the lvalue subs, so there is no special case to
handle this "legitimate" use of temporaries in lvalue subs.

Apparently Tassilo has negotiated that narrow passage when he fixed it.

Anno

 

[nobull]

[A complimentary Cc of this posting was sent to
Brian McCauley

There are bugs in Perl. In particular if the reference returned by the
%{} overload is the only reference to the tied hash some very nasty
things happen very soon. Even if it's not, nasty things seem to happen
after a while.

Could you be more specific?

http://groups-beta.google.com/group/comp.lang.perl.moderated/msg/77135c9f6d20c91a

 

[Tassilo v. Parseval]

Also sprach Anno Siegel:

[A complimentary Cc of this posting was sent to
Anno Siegel
<[email protected]>:

It looks like "temporary" refers to the state of a scalar of being
"mortal". Mortal SVs are all over the Perl source, but normally
only concern XS programmers. This is the first time I see the
distinction appear at Perl level.

There is no way to determine that a thing is mortal (short of walking
up the mortalization stack and checking whether a value is there).

Oh. I thought of it as some kind of flag in the SV. Tassilo had already
hinted as much. Obviously a little knowledge is a dangerous thing.
Apologies for posting a mere guess.

It is a flag in the SV. And previously perl only checked a combination
of flags that would normally indicated that the variable in question is
mortal and thus makes no sense to be assigned to in a lvalue context.
In my patch I merely extended this check a little: It now checks the
mortality flags and only produces the error when the value is not also a
tied hash or array element (that is: the hash/array is tied, but for
elements of these perl internally uses PERL_MAGIC_tiedelem).

Ah, but that it apparently caught in a different place:

Can't modify addition (+) in lvalue subroutine return at ...

There is now. I also wish perl didn't create temporaries for the access
to elements of tied variables (I complained about that in the journal
entry I posted a link to elsewhere in this thread). It requires a new
kind of magic for these temporaries and subsequently creates more
special cases that need to be dealt with individually.

There are other things that cannot be done with lvalue subs that I would
consider legitimate. For instance they only seem to work in scalar
context while it would be nice if they could also be used to assign to
arrays and hashes. That however could be tricky to fix.

Tassilo

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Tassilo v. Parseval

It is a flag in the SV.

Your "it" is out of context. The boring full strory: Mortality is not
a flag in SV. What triggers the warning is not mortality, and it *is*
indeed a flag in SV.

There are other things that cannot be done with lvalue subs that I would
consider legitimate. For instance they only seem to work in scalar
context while it would be nice if they could also be used to assign to
arrays and hashes. That however could be tricky to fix.

The way they were initially implemented they worked in list context -
but not the "most obvious" way. This was the most serious
limitation. Do not know what happens now...

Hope this helps,
Ilya