Re: can sub check context for lvalue vs rvalue context?

[BrowserUk]

What would your wantlvalue return if called this way:  @x = x() = 5;?

[haukex]

What would your wantlvalue return if called this way: @x = x() = 5;?

I think operator associativity can help answer that one:

$ perl -MO=Deparse -e ' @x = x() = 5; '
@x = (x() = 5);

So I'd say that x() is primarily in lvalue context here. And what's being assigned to @x is not the return value of x(), but the return value of the assignment operation, which is an lvalue itself.

$ perl -le 'sub x : lvalue { $a } (x() = 4) = 2; print $a'
2

[BrowserUk]

So I'd say that x() is primarily in lvalue context here.

That implies it has a secondary context. It doesn't. When an lvalue sub is called, it always does the same thing. Returns an lvalue to the calling context.

And what's being assigned to @x is not the return value of x(), but the return value of the assignment operation, which is an lvalue itself.

What is assigned to @x, is the result of the rvalue expression. And that, is the result of the assignment to lvalue returned by the subroutine.

[haukex]

That implies it has a secondary context. It doesn't.

Yes, of course - I was a little sloppy with my language.

And what's being assigned to @x is not the return value of x(), but the return value of the assignment operation, which is an lvalue itself.

What is assigned to @x, is the result of the rvalue expression. And that, is the result of the assignment to lvalue returned by the subroutine.

Yes, I think we're both saying the same thing here.

[perl-diddler]

What happens with Tie? Does it call a separate Store then Fetch?

Either way, a new value has to be passed into 'X', so it has to be called first in an lvalue context. Then it depends on whether or not perl makes a separate call to the function to do the equivalent of a fetch operation.

If it does, the 2nd call would call it in rvalue context, but I'd think the 2nd call wouldn't happen, as perl would already have the value it stored and not need to make a 2nd call.

[BrowserUk]

Well, its easy to demonstrate there is only one call made. So what now?

I think the easiest way to think of it, is that the function returns an lvalue to the calling context; and has no say or knowledge of how that lvalue is used there.

And in reality, that is exactly what happens:

{ my $X = 12345; sub x :lvalue { $X } };;
print x();;
12345

$r = \x();;
print x();;
12345

$$r = 456;;
print x();;
456

Think of a function returning a reference. It does not know and cannot influence whether that reference will be used to read the referent value, or assign a new value to it.

This is analogous; thus even if you knew what the context was, it would not benefit you to know. (Also why :lvalue never made it off the 'experimental' list.)

[perl-diddler]

But it does benefit me to know. If it I got that it was called in rvalue context, that would be a problem. But that it is called in lvalue context, would be what I'd need. I'd want to detect that it was called in lvalue context to give it the more expensive tied var. I could return a simple variable if it was called in rvalue context, only, as an optimization -- since reading a var is often more frequently done than setting it.

The same type of situation already arises with "wantarray":

$x = do{ my @y = func() };

You could ask "well does sub get that it was called wanting an array or not?" Even though the assignment to the array is thrown away, it will will be called with wantarray=1; To say dual use subs should have been left as "experimental" because the end result is that only the scalar value is assigned to $x, is obviously not what has been done -- subs can return arrays or scalars based on context.

The same situation holds with the no-longer-experimental ':lvalue' subs. They just need the same treatment as dual-return subs returning scalar or array -- i.e. a keyword to let the sub know context.