5

Does anyone know why "boolean not" has higher precedence than == in order of operations for most programming languages?

In mathematical logic/model theory, isn't it the other way around? I recently wrote the following in Lua:

if not 1 == 2 then
    print("hi")
end

It wasn't printing "hi" because of the order of operations between not and ==, which seems bizarre to me.

Unheilig
  • 16,196
  • 193
  • 68
  • 98
Mike
  • 51
  • 1
  • It probably makes parsing easier if all unary prefix operators have the same (high) precedence. – melpomene Nov 07 '16 at 22:45
  • 1
    Also note—in case you might get confused—Lua doesn't have any [operators](https://www.lua.org/manual/5.3/manual.html#3.4.5) (unary or binary) that take only boolean values _and_ return only boolean values. `not` takes a value of any type but does return only boolean values.(`and` and `or` are selectors.) – Tom Blodget Nov 08 '16 at 03:18

3 Answers3

5

There's never a need to negate a relational operator because each one has an opposite operator. For instance, we have both equality and inequality operators (your example could have been written 1 ~= 2). Unary operators in most programming languages have the highest precedence, because most of the time that results in code that reads more like natural language.

For instance, not green and not blue should mean "neither green nor blue". A very low precedence for not would turn that into something like not (green and not blue) which is a lot harder to make sense of.

Mud
  • 28,277
  • 11
  • 59
  • 92
1

You need to distinguish between not 1 == 2 and not (1 == 2). The latter behaves as you expect; the former is a unary not applied to 1 only, which probably produces zero.

This is not different from 'mathematical/model theory'.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • In mathematical logic "1 == 2" is considered an atomic sentence, and "not" is a boolean connective. First the truth value of all atomic sentences are evaluated, then the boolean connectives are applied. [https://en.wikipedia.org/wiki/T-schema#The_inductive_definition](https://en.wikipedia.org/wiki/T-schema#The_inductive_definition). That's what I had in mind when I said it was different from mathematical logic. – Mike Nov 08 '16 at 00:43
  • I studied mathematical logic for five years and I do not agree. – user207421 Nov 08 '16 at 00:49
  • 2
    In Lua, `not 1` evaluates to `false`, which is different from `2`, hence no output. – lhf Nov 08 '16 at 01:53
  • 2
    "You need to distinguish"? The OP's obviously knows this; it's explicitly what the post is about. You used parentheses to create the very precedence he mentioned. The question is not "how do I get `==` to have higher precedence than `not`", it's "why doesn't it already have higher precedence than `not` in programming languages"? – Mud Nov 08 '16 at 07:17
  • Not voting for this answer as `not 1` produces `false`, not `0` – Basilio German Nov 08 '16 at 21:58
  • 1
    @Mike But == can also mean double implication. – user253751 Nov 09 '16 at 01:48
0

The == operator in programming has two meanings in mathematical logic. The first is equality between elements of the domain =. The second is double implication ↔. This is, because you can compare numbers with == just like you can compare boolean values with ==.

In mathematical logic, = can only compare values of the domain, so a = b is always a boolean expression, while a and b are not. However, if we look at a ↔ b, then a ↔ b, a and b are boolean expressions. Thus, not a ↔ b means (not a) ↔ b and not a = b means not (a = b).

However, since = and ↔ are represented by the same operator == in most programming languages, it is at least very difficult and probably not intuitive to implement different precision rules for == when it is used differently.

The reason why it is difficult to implement, is because commonly, the operator precedence is implemented in the parser. When the parser translated the source code into the syntax tree, the operator precedence is already encoded in the tree. The type checking (if any) works with the syntax tree. Thus, the parser does not have access to the type information which implies that it cannot use the type information to apply different precedence rules.

Stefan Dollase
  • 4,530
  • 3
  • 27
  • 51