http://qs321.pair.com?node_id=470538

Tomtom has asked for the wisdom of the Perl Monks concerning the following question:

Hello monks,
I have a question about perl syntax :
I know that this piece of code is the correct way to do what I need :
use strict; my %hash = ( 'A' => 'on', 'B' => 'on', 'C' => 'off', 'D' => 'off', 'E' => 'off', ); for (keys %hash) { my $result = (exists $hash{$_} and $hash{$_} eq 'on') ? 'OK' : 'KO'; print $result, "\n"; }
but how comes the next piece of code ( which, in my opinion, would do the same thing ) doesn't work ? Could it be due to the exists function ( as suggested by a co-worker ) ? Here's the second piece of code :
use strict; my %hash = ( 'A' => 'on', 'B' => 'on', 'C' => 'off', 'D' => 'off', 'E' => 'off', ); for (keys %hash) { my $result; (exists $hash{$_} and $hash{$_} eq 'on') ? $result = 'OK' : $result = 'KO'; print $result, "\n"; }
In the second sample, $result is assigned 'KO' everytime, and I just don't understand why.
Does anyone have a good explanation ?

Thanks for your answers

Replies are listed 'Best First'.
Re: Question about ternary condition
by dave_the_m (Monsignor) on Jun 28, 2005 at 09:46 UTC
    Prececedence:
    (exists $hash{$_} and $hash{$_} eq 'on') ? $result = 'OK' : $result = 'KO'
    is parsed as
    ( cond ? $result = 'OK' : $result) = 'KO'
    and if cond is true, gets reduced to
    ($result = 'OK') = 'KO'
    so you assign OK, then KO, to $result. In any case, your first syntax is preferable, and the use of exists is unnecessary as the only keys you're testing are the the keys of the hash, so they must always exist

    Dave.

Re: Question about ternary condition
by robartes (Priest) on Jun 28, 2005 at 09:45 UTC

    You're being bitten by precedence. Ternary ?: has a higher precedence than =, so what perl parses is:

    Y:\tmp>perl -MO=Deparse,-p 470538.pl (my(%hash) = ('A', 'on', 'B', 'on', 'C', 'off', 'D', 'off', 'E', 'off' +)); foreach $_ (keys(%hash)) { my($result); (((exists($hash{$_}) && ($hash{$_} eq 'on')) ? ($result = 'OK') : +$result) = 'KO'); print($result, "\n"); } 470538.pl syntax OK

    You're effectively doing ($result='OK')='KO' in the case of a match, hence your output. The solution is of course to use parentheses:

    (exists $hash{$_} and $hash{$_} eq 'on') ? ($result = 'OK') : ($result = 'KO');

    Nice gotcha you found there :)

    CU
    Robartes-

Re: Question about ternary condition
by fmerges (Chaplain) on Jun 28, 2005 at 10:13 UTC

    Hi,

    Take a look at perlop, here you'll get explained the ternary operator and a indication for what is goind wrong here.

    The code really says this:

    ( (exists $hash{$_} and $hash{$_} eq 'on') ? $result = 'OK' : $result +) = 'KO';

    And the result of the ternary operator is an assignable value so that it gets to:

    $result = 'KO'

    With this, it works well

    (exists $hash{$_} and $hash{$_} eq 'on') ? ($result = 'OK') : ($result = 'KO');

    Regards,

    :-)

    Update:
    Losed too much time to answer, so it was already answered... next time ;-)
Re: Question about ternary condition
by anonymized user 468275 (Curate) on Jun 28, 2005 at 09:42 UTC
    The first example uses assignment before the ? operator so that the parts of the RHS of the assignment will be executed predictably according to the condition to the left of the '?'.

    The second example does not do any assigning before the ?. It's true that perl will execute an 'or' or 'and' in such a non-assignment context, but (IMHO) that feature cannot be assumed for all operators and apparently not '?'.

    Hope this helps.

    -S

    Update: Precedence (offered later) is a tempting explanation but I think it is merely executing both assignments in the order left to right because without an assignment to drive the ?, the parser is forced to execute the lot and then go nowhere with the ? because it has no documented reason to

    - but I do agree with using brackets to control the precedence or in this case, wake it up!

    One world, one people

      Interestingly, I've had a debate with one PerlMonk about the prudence of programming safely using parenthesis or other such practices when unsure of the exact nature of the language. He then attacked me personally and pointed out how his team of crack coding buddies would not tolerate such wasteful use of text at his company, and would proceed to point out the nuances of Perl and demand that code would be written to suit.

      I for one always applaud a programmer for erring on the safe side, regardless of what such cowboys have to say, or what disclaimers they may preface their opinions with.

        I agree with you - I've had a similar problem this year when a competing company, nervous of its previously inconsistent perl coding style set about attacking mine as a kind of defence. I was accused of unnecessarily escaping things like '_' in regexps - 'What's this \_ doing here when _ will do...?' I was asked in an aggressive manner in front of a senior manager.

        One world, one people