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

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 }"
[download]

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';
[download]

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.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.

In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Comment on Re^7: can sub check context for lvalue vs rvalue context? Select or Download Code

Replies are listed 'Best First'.
Re^8: can sub check context for lvalue vs rvalue context? by perl-diddler (Chaplain) on May 10, 2018 at 21:50 UTC
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}` [download] 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} }` [download] 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?	[reply] [d/l] [select]
Re^9: can sub check context for lvalue vs rvalue context? by BrowserUk (Patriarch) on May 10, 2018 at 22:51 UTC
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. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity. In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit	[reply]
Re^10: can sub check context for lvalue vs rvalue context? by perl-diddler (Chaplain) on May 11, 2018 at 16:19 UTC
I get your point, but I appear to be missing it because I'm never returning an rvalue. In the sample usage I've listed, I'm not using any rvalues: it's always returning the actual var, OR a tied var -- both are lvalues, but in non-lvalue context, I can return the variable directly in the belief that it is not being modified or assigned to. `$p->{_url} # simply var access (no tied usge)` [download] In the lvalue case I would need to return a more expensive case, like: `$p->{_tied_url}` [download] So I can do post-assignment-processing. It's a matter of optimization/performance -- not function. Are we on the same page yet?	[reply] [d/l] [select]
Re^11: can sub check context for lvalue vs rvalue context? by BrowserUk (Patriarch) on May 12, 2018 at 07:44 UTC
Re^12: can sub check context for lvalue vs rvalue context? by perl-diddler (Chaplain) on May 14, 2018 at 03:59 UTC
Some notes below your chosen depth have not been shown here
Re^11: can sub check context for lvalue vs rvalue context? by LanX (Saint) on May 11, 2018 at 17:02 UTC
Re^12: can sub check context for lvalue vs rvalue context? by perl-diddler (Chaplain) on May 14, 2018 at 03:53 UTC


No such thing as a small change
	PerlMonks