Timeline for Why is the logical NOT operator in C-style languages "!" and not "~~"?
Current License: CC BY-SA 4.0
35 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2020 at 9:37 | comment | added | Davislor |
@Christophe This is starting to get into speculation. But I think the historical timeline goes the other way: ! was introduced before && or || were created to be consistent with. I suggest in my answer that it might have been inspired by !=.
|
|
| Feb 28, 2020 at 9:02 | comment | added | Christophe | @Davislor because the language designers could have made the choice of consistency, if they would really have associated double ops whit logical op, to take another operator for the logical not (for retrocompatibility they could even have accepted ! as alias for ~~ before to deprecate it). But they didn‘t. Because they didn‘t have to. Because doubling was made for adressing priority and short circuit (and not to mean „logical“, as our exchange on the missing logical xor seems to confirm).In all fairness, despite your downvote, I‘ll let my upvote on your interesting & relevant contribution ;-) | |
| Feb 28, 2020 at 8:50 | comment | added | Christophe | @Davislor I think both responses are complementary (this why I upvoted yours when you wrote it). OP wondered why it was not doubled operator as all logical operators, and my focus is to explain that doubled bitwise operator is not for logic but for other reasons. This takes away the consistency argument. My explanation are backed by Ritchie’s paper. I also give a plausible reason why doubled negation was not a good idea (and my argument is true for B as well, because they could have come up with doubling in B as well). Your answer addresses the historical path. But not consistency issue. | |
| Feb 27, 2020 at 20:31 | comment | added | Davislor | @Christophe I discuss short-circuiting in my answer below. It was important, but not the only reason. | |
| Feb 27, 2020 at 20:29 | comment | added | Davislor |
@Christophe It was changed in 1976, according to Ritchie. Others remained in place: early compilers did not enforce the type system strictly, so a & &b would’ve worked. You still cannot write a--b even though the only sensible thing it could mean is a - -b, and a/*b will start a comment instead of divide by the value b points to. The tokenizer has never been (specified as) complex enough to interpret a stream of tokens based on what would make sense in the grammar.
|
|
| Feb 27, 2020 at 18:10 | comment | added | Christophe | @Davislor The doubling of logical operators in C is for short circuit only. There is no short circuit for an unary not. So no doubling. Other potential ambiguous doublings are increment/decrement, and these are not logical operators. If you don’t trust me, read Denis Ritchie’s article linked in my answer: he should know better, since he co-invented the language ;-) | |
| Feb 27, 2020 at 16:10 | comment | added | Christophe | @Davislor I don’t remember ever having seen this in K&R. | |
| Feb 27, 2020 at 12:53 | comment | added | Davislor |
@Christophe in B, the predecessor to C where ! was introduced, a=-b has the same meaning as a -= b in C. But, if not for the maximal munch rule, it could also be parsed as a = -b.
|
|
| Feb 27, 2020 at 9:10 | comment | added | Christophe | @Davislor what is ambiguous in a=-b ? | |
| Feb 27, 2020 at 2:39 | comment | added | Davislor |
I don’t think this explanation is correct. The language already had many situations that could have been ambiguous, and resolved them with the maximal munch rule. The designers allowed, for example, a=-b;.
|
|
| S Oct 4, 2019 at 10:48 | history | suggested | Ghost4Man | CC BY-SA 4.0 |
fixed and/AND ambiguity, typo (BPCL → BCPL), and mobile wikipedia links
|
| Oct 3, 2019 at 17:45 | review | Suggested edits | |||
| S Oct 4, 2019 at 10:48 | |||||
| Oct 2, 2019 at 16:18 | comment | added | Martin Bonner supports Monica |
If "logical not" had been written as ~~ then the "convert to bool operator" would just have been ~~~~ - which I quite like for it's length.
|
|
| Oct 2, 2019 at 10:14 | comment | added | Christophe | @MichaelKay Thanks for this interesting information ! | |
| Oct 2, 2019 at 10:04 | comment | added | Michael Kay | The only thing I would add is that references to "BCPL" here are references to one concrete syntax for BCPL. If you go to an early 1967 reference manual for BCPL at bell-labs.com/usr/dmr/www/bcpl.pdf you find that it used abstract syntax for operators because each machine had a different character repertoire. The abstract syntax used operators like ∧ and ∨; the concrete implementation that I programmed in represented these as /\ and \/ (slash-backslash and backslash-slash, in case that's unclear). | |
| Oct 2, 2019 at 3:30 | comment | added | ikegami |
!! can also emerge from the use of macros.
|
|
| S Oct 1, 2019 at 21:44 | history | suggested | psmears | CC BY-SA 4.0 |
Improve wording and grammar
|
| Oct 1, 2019 at 21:22 | comment | added | Christophe |
@Ruslan that's the point I tried to make in the second comment for dan. a--b doesn't compile at all. a - -b would compile. With ~ all these forms with one or two tilde would compile with different results. This is why I say it's ambiguous. I agree that additional rules could be introduced; but it would be like for ++++ where we would start to wonder it's legal and what are the priorities: the (human) ambiguity makes it error prone.
|
|
| Oct 1, 2019 at 21:08 | comment | added | Ruslan |
I think dan04 is referring to the ambiguity of --a vs -(-a), both of which are valid syntactically but have different semantics.
|
|
| Oct 1, 2019 at 21:07 | comment | added | Christophe |
@dan04 For ~~ I see it as ambiguous because ~~ could mean two different things in any context. But you are right: there could be a syntactical rule to use the longest token to disambiguate the grammar. I suppose we'd get used to (but it'll be a lot more wordy). Compared to ++, ~a would be valid, ~~a would be valid, ~ ~ a (see the spaces ?) would be valid but with a different meaning. So it would be error prone. In addition you'd have to define the priorities applicable for ~~~. Yes, for the grammar it's ok, but for humans, the potential problems start at two.
|
|
| Oct 1, 2019 at 21:00 | comment | added | Christophe |
@dan04 The expression a+ is not valid. a++ is valid a++b is not valid. a+++b is syntactically valid. a+++++b is not valid. Until two the human reader has no problem, starting with three you wonder about priorities: is it a++ + b or a + ++b and you'd end up on SO to find out if your interpretation is portable ;-)
|
|
| Oct 1, 2019 at 20:09 | comment | added | dan04 |
How would ~~ introduce any more ambiguity than ++ and --?
|
|
| Oct 1, 2019 at 13:50 | comment | added | R.. GitHub STOP HELPING ICE |
!! is not only possible/reasonable to write, but the canonical "convert to boolean" idiom.
|
|
| Oct 1, 2019 at 10:08 | review | Suggested edits | |||
| S Oct 1, 2019 at 21:44 | |||||
| Oct 1, 2019 at 5:12 | comment | added | Ben |
@user2357112 I think the point is that it's okay to have the tokenizer blindly take && as a single && token and not as two & tokens, because the a & (&b) interpretation isn't a reasonable thing to write, so a human would never have meant that and been surprised by the compiler treating it as a && b. Whereas both !(!a) and !!a are possible things for a human to mean, so it's a bad idea for the compiler to resolve the ambiguity with an arbitrary tokenization-level rule.
|
|
| Oct 1, 2019 at 1:34 | comment | added | user2357112 |
&& isn't actually disambiguated from two instances of & at parser level; it's disambiguated at tokenization level. If you tried to design it so the disambiguation was based on two &s not making sense in the type system, then the parser would have to understand the types of expressions, and a & & b would be a valid logical AND expression.
|
|
| Sep 30, 2019 at 19:49 | comment | added | Christophe | @Steve I was indeed a little bit too fast in my formulation. I've edited to present two aspects: the human reader and the parser. Hope this clarifies the point you've raised. | |
| Sep 30, 2019 at 19:45 | history | edited | Christophe | CC BY-SA 4.0 |
added 236 characters in body
|
| Sep 30, 2019 at 18:47 | vote | accept | Martin Maat | ||
| Sep 30, 2019 at 18:47 | vote | accept | Martin Maat | ||
| Sep 30, 2019 at 18:47 | |||||
| Sep 30, 2019 at 18:25 | comment | added | Eric Lippert |
@Steve: Indeed, there are many similar problems already in C and C-like languages. When the parser sees (t)+1 is that an addition of (t) and 1 or is it a cast of +1 to type t? C++ design had to solve the problem of how to lex templates containing >> correctly. And so on.
|
|
| Sep 30, 2019 at 14:03 | comment | added | BobDalgleish | The parser is unable to disambiguate the two situations, therefore the language designers must do so. | |
| Sep 30, 2019 at 12:10 | comment | added | Steve | "cannot be misinterpreted ... since it is a binary operator" - does that not put the cart before the horse, since it is the task of the parser to determine (as a prior question) whether a particular sequence of characters is a binary operator, or an unary operator applied twice? Presumably it is the order of precedence or a fixed rule that resolves the ambiguity - it is not inherently unambiguous. | |
| Sep 30, 2019 at 12:00 | history | edited | Christophe | CC BY-SA 4.0 |
added 239 characters in body
|
| Sep 30, 2019 at 11:53 | history | answered | Christophe | CC BY-SA 4.0 |