I'm posting this in Meditations instead of Seekers because it seems there is no such operator; I just read man perlop.

Anyhow, those familiar with logics might be familiar with "implication" operator: A -> B, from A follows B, or in more primitive terms: !A || (A && B). Used to say things like "if it rains, then it winds" - if it doesn't rain, the statement might as well be true but not applicable, if it does rain then we'll see if the statement is true by checking if it winds too.

My point? That perl should have one. It may sound like trivial operator ... but believe it or not, I actually encountered a case where it would have come in handy. I am writing this personal web proxy in perl that tampers with CGI requests. Now, multipart POST requests didn't go through because, in case of POST, I just fed the body to CGI.pm which interpreted it all wrong. Upon writing a check to only accept content-type: application/x-www-form-urlencoded, I ended up writing as following:

($method ne "post" || ($method eq "post" && $contenttype eq "application/x-www-form-urlencoded")

As you can clearly see, it would have been better written

($method eq "post") -> ($contenttype eq "application/x-www-form-urlencoded)

(of course, => operator is already in use. And so is ->.)

Still, with current operatorness, the way I wrote it is unsatisfactory. It duplicated terms ($method ne "post" vs. $method eq "post"), which is equivalent to code copying, which is Bad Thing. Right? I can think of some more ways to write this, but they all end up copying terms, so I suspect there really isn't way to make it neat with what there is.

So, maybe there should be implication-operator? And now that I think of it, why isn't there high-precence XOR operator (one corresponding to && and ||, "xor" is impractical with too low precedence)? Is it that they simply couldn't figure out proper characters for them?

...

OK, OK, I admit this might be a "bit" trivial issue but this really troubles me. And this is "Meditations" which apparently is cover name for "Ramblings", isn't it?

-Kaatunut

Replies are listed 'Best First'.
Re: Implication operator
by chipmunk (Parson) on Dec 11, 2000 at 03:54 UTC
    It's an interesting idea, but I don't think there's a need for an implication operator, because !A || (A && B) is logically equivalent to !A || B
[reply]
[d/l]
[select]
Re (tilly) 1: Implication operator
by tilly (Archbishop) on Dec 11, 2000 at 05:19 UTC
    As was already pointed out, you can get implication already with: 
      (A and not B)

    [download]
    (just look at the truth-table). As for your example, it can be cleanly written with: 
      ($method ne "post") or ($contenttype eq "application/x-www-form-urle
+ncoded)

    [download]
    since you are never falling through the or unless the method is "post".

    In fact I find the form I wrote easier to follow than the version with the implication operator that you asked for. There does come a time when offering many logically equivalent ways to say the same thing lends to confusion, and I think this crosses that line. (As does "unless" and "until" quite often.)

[reply]
[d/l]
[select]
Re: Implication operator
by Fastolfe (Vicar) on Dec 11, 2000 at 07:38 UTC
    Just because 'xor' is low-precedence doesn't mean you can't use it. Just wrap expressions in parenthesis so that Perl knows what it needs to evaluate first. 
    if ($a xor $b) { ... }
if ($a || $b xor $c || $d) { ... }
if (($a xor $b) || ($c xor $d)) { ... }

    [download]
[reply]
[d/l]
Re: Implication operator
by clemburg (Curate) on Dec 11, 2000 at 15:29 UTC

    Man, think before you request features in the core language. You *are* allowed to define your own subroutines in Perl.

    I would really think that 

    ($method eq "post") -> ($contenttype eq "application/x-www-form-urlenc
+oded)

    [download]

    is better written (in terms of self-explaining code) as: 

    implies(($method eq "post") => 
        ($contenttype eq "application/x-www-form-urlencoded))

    [download]

    and you even get your arrow, visually.

    Why does everybode want *operators* when they can have *functions* for nothing?

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

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

[reply]
        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]
        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]
Re: Implication operator
by mrmick (Curate) on Dec 11, 2000 at 20:14 UTC
    I LIKE this thread! It got me thinking (a tough thing to do on Monday morning) and even enlightened me a bit about implication operators. Especially the discussion that followed the original post.

    This thread is a perfect example of TMTOWDTI.

    By the way... I don't really think a new operator is needed for this type of functionality but it would be cool.

    Mick
[reply]

Back to Meditations