Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 30 down vote favorite
4

It might be a strange question, but why there is no implication as a logical operator in many languages (Java, C, C++, Python Haskell - although as last one have user defined operators its trivial to add it)? I find logical implication much clearer to write (particularly in asserts or assert-like expressions) then negation with or:

encrypt(buf, key, mode, iv = null) {
    assert (mode != ECB --> iv != null);
    assert (mode == ECB || iv != null);
    assert (implies(mode != ECB, iv != null)); // User-defined function
}
share|improve this question
14  
Because it wasn't put in C; if it have been put then C++, Java and C# would have had it. – m3th0dman Jan 18 at 13:17
3  
But C doesn't have it, in turn, because it's not a common part of assembly language. Whereas as all instruction sets I know of include and, or and not, I know of none that include implies - no doubt someone will be along to tell me of some obscure instruction set that does shortly... – Jack Aidley Jan 18 at 14:30
1  
@JackAidley: Not exactly implies but Intel's MMX have and not which is inverse of the implies. If ISA in general constitute something obscure nowadays is of course matter of debate. – Maciej Piechotka Jan 18 at 14:50
2  
Maybe it was considered redundant because (1) it is less primitive than "^", "v", "~", (2) it saves very little typing since "A => B" is equivalent to "~A v B". – Giorgio Jan 18 at 14:50
2  
Languages that deal with logical constructions are more likely to have it. Chiefly among these is prolog – MichaelT Jan 18 at 15:22
show 5 more comments

4 Answers

up vote 31 down vote accepted

It could be useful to have sometimes, no doubt. Several points argue against such an operator:

  • The characters - and > are valuable, both in isolation and combined. Many languages already use them to mean other things. (And many can't use unicode character sets for their syntax.)
  • Implication is very counter-intuitive, even to logic-minded people such as programmers. The fact that three out of the four truth table entries are true surprises many people.
  • All other logical operators are symmetrical, which would make -> an exception to orthogonality.
  • At the same time, there is an easy workaround: use ! and &&.
  • Implication is used vastly less often than logical and/or.

This is probably why the operator is rare today. Certainly it could become more common, as new dynamic languages use Unicode for everything and operator overloading becomes more fashionable again.

share|improve this answer
13  
Your first point only argues against using '-->' as the symbol for the operator, not against actually having the operator. The others are good points. – AShelly Jan 18 at 14:21
8  
"At the same time, there is an easy workaround: use ! and &&.": In fact, the simplest way of simulating "->" (or "=>", as it is more common in Math), is to use ! and ||, not ! and &&: A -> B is equivalent to !A || B which is equivalent to !(A && !B). – Giorgio Jan 18 at 14:53
9  
"The fact that three out of the four truth table entries are true surprises many people." Wat. I know another operator with the same feature which is used rather often... – l0b0 Jan 18 at 18:09
@l0b0 Yeah, but for or, that's what everyone expects. The same doesn't apply to implication. – svick Jan 20 at 1:16
@svick: These blanket statements about other developers is a bit strange. I'd expect people who have studied CS to think something like "anything can follow from a false premise, while a true premise can only lead to a true result." – l0b0 Jan 20 at 9:06
show 2 more comments
up vote 29 down vote

I believe the answer lies in the mathematical foundations. Implication is usually considered and defined as an derived, not elementary, operation of boolean algebras. Programming languages follow this convention.

share|improve this answer
+1 - solid answer. Boolean algebra and the simplifications in logic that it allows drives a lot of programming methodology. Using an "implies ..." would potentially interfere with "don't care" conditions. – GlenH7 Jan 18 at 14:34
1. That depend on definition. It is possible to define or as a || b = !(!a && !b) (I met or as derived operator in logic). 2. The reason why it is done is usually to simplify induction proves I believe (we know that derived operators are just short-cuts so we don't need to have separate case for them). @GlenH7: What "don't care" conditions? a --> b is the same as !a || b. – Maciej Piechotka Jan 18 at 14:55
2  
Also - we have other derived operators like xor (!=) nxor (==)... – Maciej Piechotka Jan 18 at 14:57
1  
Actually, you can derive everything from either NAND !(a && b) or NOR !(a || b). For example, NOT a == a NAND a, a AND b == NOT(a NAND b), a OR b == (NOT a) NAND (NOT b). But providing only a NAND operator puts you in the realm of esoteric languages (which fits surprisingly well, given the answerer's username ;-) ). – Stefan Majewsky Jan 18 at 22:17
@MaciejPiechotka: True, this depends on definition. Just about everything in mathematics depends on definitions. And sure, (!=) and (==) could be interpreted as xor and xnor (though I wouldn't consider them boolean operators at all). What I wanted to point out is that there are conventions about definitions and specifically about definitions of Boolean algebras. Furthermore, there are reasons and history behind these conventions, and that history goes way beyond the scope of modern programming languages. – COME FROM Jan 22 at 11:13
up vote 13 down vote

I can only guess, but a reason might be that there are workarounds which are quite simple and readable. Let's consider your example:

if (mode != ECB) assert (iv != null);

assert (mode != ECB --> iv != null);  // <-- that's only one character shorter

If you need an expression, the inline-if operator available in most languages (often called the ternary operator) can be used. Granted, this is not as elegant as A --> B, but the number of use cases might not justify adding (and maintaining!) another operator:

assert (mode != ECB ? iv != null : true);
share|improve this answer
1  
As of asserts - there is good reason. First one will produce (in many implementations) message "assertion failure: iv != null" while second "assertion failure: mode != ECB --> iv != null". – Maciej Piechotka Jan 18 at 14:56
2  
+1, I was about to ask this same thing on the question (since I'm not very familiar with "implication", it never comes up day-to-day). The if statement is far, far clearer to just about everyone. – Izkata Jan 18 at 19:16
up vote 12 down vote

Visual Basic 6 (and VBScript) had Imp and Eqv operators. No one used them. Both were removed in VB.NET; to my knowledge, no one complained.

I worked on the Visual Basic compiler team (as an intern) for a full year and never once noticed that VB even had those operators. Had I not been the guy writing the VBScript compiler, and therefore had to test their implementations, I probably would not have noticed them. If the guy on the compiler team doesn't know about the feature and doesn't use it, that tells you something about the popularity and usefulness of the feature.

You mentioned C-like languages. I can't speak to C or C++ or Java but I can speak to C#. There is a list of user-suggested features for C# literally longer than your arm. To my knowledge, no user has ever proposed such an operator to the C# team, and I've gone over that list many, many times.

Features that exist and are unused in one language, and are never requested in another are unlikely candidates to make it into modern programming languages. Particularly when there is not enough time and effort and money available in the budget to make features that people do want.

share|improve this answer
IMP goes back as an operator to GWBASIC days. I remember it from 1979. – zarchasmpgmr Jan 21 at 21:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.