&& is not an lvalue

Discussion in 'Perl Misc' started by xhoster@gmail.com, Jul 31, 2008.

  1. Guest

    It seems like almost everything in Perl is an lvalue. So why isn't the
    result of && an lvalue?

    I wanted to do this:
    ($h{$big}{$nasty}[$dereferencing]{operation($x)}{$done}[here(y)]and die)=6;


    Obviously, that just isn't the way perl was implemented. But is there a
    reason that "?:" yields an lvalue but && doesn't?

    Thanks,

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Jul 31, 2008
    #1
    1. Advertising

  2. Ben Morrow Guest

    Quoth :
    > It seems like almost everything in Perl is an lvalue. So why isn't the
    > result of && an lvalue?
    >
    > I wanted to do this:
    > ($h{$big}{$nasty}[$dereferencing]{operation($x)}{$done}[here(y)]and die)=6;
    >
    > Obviously, that just isn't the way perl was implemented. But is there a
    > reason that "?:" yields an lvalue but && doesn't?


    Perhaps because it's not entirely clear which operand would be returned
    when both are true or both false? That doesn't apply to your case, of
    course, since one of them is 'die' and can never be returned, but perl
    doesn't know that.

    Which one you actually get is rather confusing. If either is false, you
    get that one; if both are false, you get the first; and if both are
    true you get the second. || is the other way around: both false gives
    the second operand, and both true the first. I suppose it makes sense
    when you consider the short-circuiting.

    Oddly, you *can* take a ref to the result of && (which is in fact an
    lvalue), which means

    ${\( $x and die )} = 6;

    *does* work as you expect, despite being hideously ugly.

    Even stranger, while do { $x } returns $x (though of course you can't
    assign to it directly), if the expression inside the 'do' gets too
    complicated it starts returning a copy instead:

    ~% perl -le'print \do { $x }; print \$x'
    SCALAR(0x8100be0)
    SCALAR(0x8100be0)
    ~% perl -le'print \do { $x and 1 }; print \$x'
    SCALAR(0x8100be0)
    SCALAR(0x8100be0)
    ~% perl -le'print \do { $x and die }; print \$x'
    SCALAR(0x810016c)
    SCALAR(0x8100be0)
    ~% perl -le'print \do { $x; $x }; print \$x'
    SCALAR(0x810016c)
    SCALAR(0x8100be0)

    The point at which it switches over appears to be when the do block gets
    its own ENTER/LEAVE ops rather than just being a scope.

    A clean way around the problem is to use Data::Alias:

    use Data::Alias;

    alias my $tmp = $h{......}
    and die ...;
    $tmp = 6;

    Ben

    --
    All persons, living or dead, are entirely coincidental.
    Kurt Vonnegut
     
    Ben Morrow, Jul 31, 2008
    #2
    1. Advertising

  3. Ben Morrow wrote:
    > Quoth :
    >>
    >> is there a reason that "?:" yields an lvalue but && doesn't?

    >
    > Perhaps because it's not entirely clear which operand would be
    > returned when both are true or both false?


    && is defined to return the last thing evaluated. How is that not clear?

    > Which one you actually get is rather confusing.


    I don't think that the behavior of the operator isn't confusing at all.
    Any code that makes use of that behavior is likely to be if only because
    it's so rarely used.

    -mjc
     
    Michael Carman, Aug 1, 2008
    #3
  4. Guest

    Ben Morrow <> wrote:
    > Quoth :
    > > It seems like almost everything in Perl is an lvalue. So why isn't the
    > > result of && an lvalue?
    > >
    > > I wanted to do this:
    > > ($h{$big}{$nasty}[$dereferencing]{operation($x)}{$done}[here(y)]and
    > > die)=6;
    > >
    > > Obviously, that just isn't the way perl was implemented. But is there
    > > a reason that "?:" yields an lvalue but && doesn't?

    >
    > Perhaps because it's not entirely clear which operand would be returned
    > when both are true or both false? That doesn't apply to your case, of
    > course, since one of them is 'die' and can never be returned, but perl
    > doesn't know that.
    >
    > Which one you actually get is rather confusing. If either is false, you
    > get that one; if both are false, you get the first; and if both are
    > true you get the second. || is the other way around: both false gives
    > the second operand, and both true the first. I suppose it makes sense
    > when you consider the short-circuiting.


    Yep. And I was consider short-circuiting, so I didn't find it all that
    confusing. Off the top of my head, I can't think if anything I'd use this
    for that didn't have a die as the second. (but I probably wouldn't use
    that construct in anything except one-offs or one-liners, anyway.)

    >
    > Oddly, you *can* take a ref to the result of && (which is in fact an
    > lvalue), which means
    >
    > ${\( $x and die )} = 6;
    >
    > *does* work as you expect, despite being hideously ugly.


    Yeah, I did that experiment myself. But I didn't make the valid deduction
    that you have, that it actually is an l-value, just an l-value which
    the compiler pitches a fit over. Which makes it even stranger to me.
    It seems like the programmers must have went out of their way to make
    this syntax error happen, rather than it being a natural consequence of
    something else.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    The costs of publication of this article were defrayed in part by the
    payment of page charges. This article must therefore be hereby marked
    advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
    this fact.
     
    , Aug 1, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Biber

    Re: Why is this not a modifiable lvalue.

    Simon Biber, Jun 27, 2003, in forum: C Programming
    Replies:
    0
    Views:
    2,403
    Simon Biber
    Jun 27, 2003
  2. Dan Pop

    Re: Why is this not a modifiable lvalue.

    Dan Pop, Jun 27, 2003, in forum: C Programming
    Replies:
    6
    Views:
    4,997
    Dan Pop
    Jun 30, 2003
  3. Kavya
    Replies:
    9
    Views:
    541
    Dik T. Winter
    Oct 28, 2006
  4. Replies:
    11
    Views:
    715
    James Kuyper
    Sep 22, 2008
  5. Julian Mehnle
    Replies:
    0
    Views:
    258
    Julian Mehnle
    Jul 17, 2003
Loading...

Share This Page