in reply to Re: Implication operator
in thread Implication operator

First, I'd like to note that people above are absolutely correct; it was incredibly stupid from me not to realize the power of short-circuit ||. Well, to be exact, I did consider some sort of short-circuit tricks but for some reason I couldn't figure that out.

As for you point, I don't agree. Operators are generally better read than functions for two-way operations, at least for english speakers, don't you think? Saying "implies A to B" when you mean "A implies B" is just plain weird, and if you disagree, replace word 'implies' with 'and'; they're both binary operators. "and(A,B)" doesn't sound that good, does it?

Besides, as of perl5-something, => forces left side to be string. Hmm. I wonder if that does any harm, though... I can't bother go experimenting with that.

...

Besides, as I said, it was minor issue, don't confuse me for princepawn reborn for talking about perl core when I'm barely an Adept :I I just still think that implication operator would look neater than function call - where needed; it might not be needed.

As for xor precedence, my point holds, "xor" operator has so cumbersomely low precedence that I have to be throwing parenthese (sp?) here and there not to break something. Not nice.

 -Kaatunut

Replies are listed 'Best First'.
Re: Re: Re: Implication operator
by chipmunk (Parson) on Dec 11, 2000 at 21:38 UTC
    Actually, => only forces the left side to be a string if it is a bareword. If the left side is not a bareword, it's the same as a comma.
[reply]
Re: Re: Re: Implication operator
by Fastolfe (Vicar) on Dec 11, 2000 at 21:26 UTC
    Update: As chipmunk indicates, ^ is more akin to | than || (bit-wise versus otherwise) and it does not make sense to use it as a comparison operator. So while xor can still be used, given its low precedence, akin to 'or' in comparisons, it does not have a '^^' counterpart akin to ||, which could be potentially very useful. I'm keeping the rest of this post here for historical purposes.

    I don't really share your feelings about 'xor' precedence. Two situations where its precedence allows you to forego parenthesis: 

    if ($a || $b xor $c || $d) { ... }
if ($a xor $b) { ... }

    [download]
    In the first example, would you rather xor's precedence be higher than ||? Now look at what we have to do: 
    if (($a || $b) xor ($c || $d)) { ... }

    [download]
    If we want to do swap the xor/|| operators, I can possibly see the advantage, but really any complex situation like this is going to almost require you to use paranthesis in order to show Perl how you want things evaluated. Perhaps you are confusing 'xor' with the bitwise/integer xor operator (^), which has a much higher precedence. See perlop. 
    if ($a ^ $b || $c ^ $d) { ... }

    [download]
    Realistically (and I don't know why I didn't mention this before), this should probably be used in expressions instead of 'xor', unless you need something that's low precedence (like using 'or' or 'and' in expressions).
[reply]
[d/l]
[select]
      Using a bitwise xor operator as a logical xor operator can be dangerous. 
      sub true {
  return 1;
}

sub True {
  return 2;
}

if (true() xor True()) {
  print "xor is true.\n";
}

if (true() ^ True()) {
  print "^ is true.\n";
}

__END__
^ is true.

      [download]
      The obvious choice for a high-precedence logical xor is ^^. It's consistent with && and ||, and it doesn't conflict with anything already in the language.
[reply]
[d/l]
        True enough! For some reason I was thinking along the lines of comparisons, and in my head I placed &&, || and ^ in the same boat, when it really needs to be && and || in one boat and ^, | and & in another. I agree that something like ^^ might be nice.
[reply]

In Section Meditations