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

[perl-diddler]

I have a feeling we are not using the same terms as having the same meaning.

When I return an lvalue, in my mind, I'm returning the address of an object so that the compiler/interpreter can put something in it (has happens to the left side of an assignment).

Vs. if I return an rvalue, In my terminology, I'm only returning the value that was in that address -- so the compiler/interpreter can't assign a new value into the variable location.

If I return an lvalue, the compiler can store a new value. But it can also propagate that value to another lvalue. No problem: I don't care. What I care about is detecting that my lvalue sub has been assigned to (whether or not the value changes is irrelevant).

The rvalue context I would detect in a statement like:

if ($p->url) {...}

would allow me to return an actual value and not a tied var.

It's the 'lvalue' case where I need to presume that the value in 'url might change, and thus return a more expensive (ex. tied) version so I can update the url's component values.

I don't see how that is problematic.

[BrowserUk]

I don't see how that is problematic.

Semantically, it is problematic because it is not possible the way things are at the moment; and if it is changed, it will break existing code -- which is p5p generally consider sacrosanct.

In my terminology, I'm only returning the value that was in that address -- so the compiler/interpreter can't assign a new value into the variable location.

Implementation wise, lvalue subs always return an lvalue. That's why any attempt to return a constant from an lvalue sub causes an error:

sub x :lvalue { 1 };;
[Can't modify constant item in lvalue subroutine return at (eval 18) l
+ine 1, near "1 }"

If that was allowed, then x() = 2; would modify that constant.

And even if you only returned an rvalue ("the value that was in that address") when you detected that you were called in an rvalue context -- were that possible -- then it would still break this code:

my $ref = \x(); ## lvalue context, no assignment.

... some time later assign through the ref taken.

$$ref = 'anything at all';

Currently, and since their inception, that has be both legal and useful.

For a change to be made such that returning an non-lvalue from an lvalue sub was (conditionally) possible; would break any existing code; and the expectation.

FWIW: I wish lvalue subs could inspect the value they are assigned; but I was told very firmly a long time ago that would never be possible; because any assignment happens after the sub returns, in the calling context, long after the sub is finished.

[perl-diddler]

I don't need to return a constant under any circumstance, but if I know I am returning an rvalue, I can return:

p->{_path}

If something is being assigned to 'path', then I'd know I need the lvalue -- and return something like

$p->{tied_path}

sub callback_for_STORE_into_tied_path { my $p=shift;
  my $newvalue;
  $p->{_path}=$newvalue;
  $p->{_url}=undef;
  ...
  $p->{_path};
}
...later...in 
sub url(;$) { my $p=shift;
  $p->compose_url_from_parts() unless defined $p->{_url};
  $p->{_url}
}

So if someone want to read path, they would get a simple, direct reference (no tied var overhead), but if they wrote to it, it needs to store the new value, and clear the internal value for _url so it can be re-composed.

At no point should I need to return a constant -- just a choice between the actual var in the hash, or a tied var.

If I knew the lvalue-context, is there a reason why that wouldn't work?

[BrowserUk]

I don't need to return a constant

You miss the point entirely. (I beginning to wonder if it is deliberate.)

If you return anything that is not an lvalue, it is a constant. The very definition of rvalue, is "unassignable". Perl won't let you do that.

[ikegami]

The actual difference between an :lvalue sub and one that isn't returns a copy of the scalar that would otherwise be returned.