in reply to Re^3: can sub check context for lvalue vs rvalue context?
in thread can sub check context for lvalue vs rvalue context?

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() };

[download]

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.

Replies are listed 'Best First'.
Re^5: can sub check context for lvalue vs rvalue context?
by BrowserUk (Patriarch) on May 10, 2018 at 07:19 UTC
    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.

    (Part of) My point is that the caller can take a reference to whatever you return, and at some point later dereference that pointer and assign through it; with the expectation that the next time they call your sub, it will return the new value they've assigned; but taking a reference is explicitly an rvalue operation.

    If you could detect the rvalue context and returned "a simple rvalue", you break that expectation.

    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]
      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) {...}

      [download]
      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.

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

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

[reply]

In Section Seekers of Perl Wisdom