develooper Front page | perl.perl5.porters | Postings from April 2012

Re: proposal: functional C<if>

Thread Previous | Thread Next
From:
Brad Baxter
Date:
April 26, 2012 07:31
Subject:
Re: proposal: functional C<if>
Message ID:
CANBtU9bVX_2hRJTf9vD++_TJwAOXo0Fi39VUMzpTtJXiiLWeXQ@mail.gmail.com
On 4/25/12, David Nicol <davidnicol@gmail.com> wrote:
> The proposal appears to be, allow
>
>      if ( BOOLEAN ) { TRUE BRANCH } else { FALSE BRANCH }
>
> and variations (unless, elsif, elsunless (do we even have that?) and so on)
>
> to act as R-values in assignment and elsewhere. In effect, making that
> syntax exactly a long way to write the ternary operator.
>
> An if-statement already sort of returns a value, but it can only be
> captured by enclosing the if-statement in a block of some kind, so the
> value gets returned
> according the "value of a block is the value of the last expression
> executed" rule.

If I'm following, the initial challenge is recognizing when an
'if(unless)/elsif/else' construct is intended to be an expression
(EXPR).

If that hurdle is passed, then I suppose you could pretend you had a
'do{if...}' and get an R-value.  But what if you pretend you had a
(possibly nested) ternary?  Wouldn't that buy you an L-value, too?

Just wondering.

-- 
Brad

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About