5 ms·

> It depends… on operator precedence I think implementing operator precedence in ANY programming language is a mistake. `1 + 1 * 2` should be a syntax error. I

by boxed 3y ago

> It depends… on operator precedence I think implementing operator precedence in ANY programming language is a mistake. `1 + 1 * 2` should be a syntax error. In C, in Python, in Java.

tempodox 3y ago
I vigorously disagree.
- lionkor 3y ago
  For that example, I agree, but how about a | b || c >> d & e * f ? I think its reasonable to say that a language should not allow that
  - OJFord 3y ago
    You can take any reasonable grammar and come up with unreasonably ugly/illegible code.
    - lionkor 3y ago
      Yeah, of course, but grammar can be designed as to not allow as much implicit magic. If you can do it, someone will do it (in prod, in your product).
  - tempodox 3y ago
    The reason why this expression shouldn't compile has nothing to do with precedences (C has some odd choices here to be sure), but because of mixing incompatible types. Arithmetic integers, bitvector integers, Booleans, and possibly even floats. Conversions to appropriate types should have to be explicit. But C's type system is weak as all hell and this shit actually compiles there. (I'm only mentioning C because your example looks like it.)
    - rfl890 3y ago
      There‘s no implicit type conversion here. As long as all the vars are the same type it works (albeit unpredictable if you don‘t know operator precedence for the lang).
  - bmacho 3y ago
    How about *paste Linux source code here*? Should the language C allow it? It's long and complicated, you don't even have enough time to read it, let alone to comprehend it.
  - samatman 3y ago
    That expression would not pass code review around me, and a linter should flag it for sure. But all the precedence rules you're invoking here are useful in isolation, and I see no reason why they shouldn't parse in combination. A linter can use heuristics to flag cases which should be parenthesized, a parser would need a defensible rule for failing a parse. What would that rule be?
sokoloff 3y ago
There is value in notational simplicity. For the same reason that math has defined precedence (and even omits multiplication signs entirely in many places), programming languages in some domains will choose to do the same. It’s not a problem if you want to create a language that does not do this, but I think it is a problem if you want to ban others from doing it.
- tsimionescu 3y ago
  Algebra only really has defined precedence between multiplication and addition/subtraction. In all other cases, even division, there is either a non-linear textual representation, or parantheses are required. You have fractions, exponents, radical signs, various signs which appear only at the beginning of an expression (sigma, integral, lim) etc. Even multiplication is often distinguished more by the shape of the text than by actual precedence rules, once you leave basic arithmetic - expressions like "1 - 3xy + 2y²" make the order of operations obvious from text layout, which is why they are preferred over "1 - 3 × x × y + 2 × y ^ 2", which no mathematician ever writes.
  - sokoloff 3y ago
    Exponentiation also has defined precedence, does it not? (Everyone who has passed algebra agrees that y is squared before being multiplied by 2 in your example.)
    - tsimionescu 3y ago
      You can view that as precedence, but I think it's more correct to say that exponentiation binds to the single symbol it is attached to. When you write x² + 2, I don't think it's operator precedence that makes it clear this is not equal to x ^ 4. Similarly, in the following expression: x _ + 2 2 I don't think it's precedence that makes it clear you first divide by 2 and then add 2 to the result.
      - sokoloff 3y ago
        Alternatively, perhaps what you're observing is simply the graphical representation of the underlying mathematical precedence rules. (Obviously, over hundreds of years of symbolic math, the notation and precedence has co-evolved, with precedence probably generally, well, preceding notation.) y = x / 3 + 2 y = 2 + x / 3 y = x/3 + 2 We all agree those are the same, despite a lack of an any cues in the first two. That suggests to me that there is a defined precedence for division vs addition in math. (So much so that it doesn't even seem like a controversial statement to make.)
lifthrasiir 3y ago
Some operator precedences are way more reasonable than others, and those between arithmetic operators are good examples. What we actually need is a partial order of operator precedences: you can have `1 * 2 + 3` or `full_name ?? first_name ++ " " ++ last_name` but not necessarily `1 * 2 & 3` because that combination of operators is uncommon and a parenthesis should be preferred instead of an arbitrary total order.
zarzavat 3y ago
Should `x == 1 or y == 3` be a syntax error? Because that’s operator precedence too.
- kragen 3y ago
  that's certainly a plausible position; in lisp (or = x 1 = y 3) is generally an error; even if it's not an error it doesn't mean what you intend it to. having to write (x == 1) || (y == 3), similar analogous to the code you'd write in lisp, would be only a minor burden in c, x == 1 || y == 3 works fine, but unfortunately the bitwise operators have the wrong precedence; x & 2 == 2 is parsed as x & (2 == 2), which is never what you meant. so even the best software designers have made terrible blunders in precedence design math formulas are a bigger issue; 3*x**2 + x/2 + 1 is a lot better than the fully parenthesized version
  - zarzavat 3y ago
    There are of course operations with unclear precedence relationships and it’s completely reasonable to want to force parentheses when composing those operations. However, there are also operations with crystal clear precedence relationships, such as logical conjunction and comparison, and in that case it has to be asked what exactly would the parentheses be there for? In lisp the answer is: to enable syntactic homogeneity and to enable macros. But in other languages like Python that don’t have sexpr based syntax, parenthesizing everything would just be pointlessly unreadable.
    - kragen 3y ago
      it isn't crystal clear to everyone, smart guy, it's only clear if you're familiar with it
- ctrw 3y ago
  That is type inference actually.
- boxed 3y ago
  yea it should
frud 3y ago
For basically forever compilers and languages have been designed with a total ordering on operator precedences. The Yacc compiler generator tool maps operator precedence to integers, as do most handwritten compiler parsers. A total ordering has a definite answer to the question "is x greater than, equal to, or less than y?" for all x and y. A partial ordering will answer "I don't know" for some x and y. It's quite possible to implement operator precedence using a partial ordering. When the parser has to resolve precedence between two operators and their relationship is not defined, throw an "ambiguous precedence" error. You can implement the partial ordering by putting all the operators into a DAG of sets of operators. If two operators are in the same set, they have equal precedence. If there is a path through the DAG from one operator to the other, that defines the precedence relation. Else there is no relation. Say "*" is defined to have a higher precedence than "+", and they both have an undefined precedence relation with "&". Then "1 + 2 * 3" should compile into "1 + (2*3)", but "1 + 2 & 3" should throw an "ambiguous precedence" syntax error.
adrian_b 3y ago
The lack of operator precedence has no relationship with the mandatory use of parentheses. For example the APL syntax for expressions, which I prefer, is that there is no operator precedence. The operands are associated to operators strictly from the right to the left, regardless which operators or functions are used, which is a much wiser choice than the reverse traditional order of evaluation. No parentheses are used, except when they are needed to modify the default evaluation order.
samatman 3y ago
That would get really annoying. Not in expressions like 1 + 3 * 6. Personally, I include the parentheses anyway, as a matter of style, and would write 1 + (3 * 6). But in expressions like i + 3 > 4 / n? No thank you, (i + 3) > (4 / n) would drive me up a wall. Ymmv.
recursivedoubts 3y ago
preach king https://hyperscript.org https://hyperscript.org doesn’t allow mixing different infix operators w/o parentheses

by boxed 3y ago

> It depends… on operator precedence I think implementing operator precedence in ANY programming language is a mistake. `1 + 1 * 2` should be a syntax error. In C, in Python, in Java.

tempodox 3y ago

I vigorously disagree.

lionkor 3y ago
For that example, I agree, but how about a | b || c >> d & e * f ? I think its reasonable to say that a language should not allow that
- OJFord 3y ago
  You can take any reasonable grammar and come up with unreasonably ugly/illegible code.
  - lionkor 3y ago
    Yeah, of course, but grammar can be designed as to not allow as much implicit magic. If you can do it, someone will do it (in prod, in your product).
- tempodox 3y ago
  The reason why this expression shouldn't compile has nothing to do with precedences (C has some odd choices here to be sure), but because of mixing incompatible types. Arithmetic integers, bitvector integers, Booleans, and possibly even floats. Conversions to appropriate types should have to be explicit. But C's type system is weak as all hell and this shit actually compiles there. (I'm only mentioning C because your example looks like it.)
  - rfl890 3y ago
    There‘s no implicit type conversion here. As long as all the vars are the same type it works (albeit unpredictable if you don‘t know operator precedence for the lang).
- bmacho 3y ago
  How about *paste Linux source code here*? Should the language C allow it? It's long and complicated, you don't even have enough time to read it, let alone to comprehend it.
- samatman 3y ago
  That expression would not pass code review around me, and a linter should flag it for sure. But all the precedence rules you're invoking here are useful in isolation, and I see no reason why they shouldn't parse in combination. A linter can use heuristics to flag cases which should be parenthesized, a parser would need a defensible rule for failing a parse. What would that rule be?

sokoloff 3y ago

There is value in notational simplicity. For the same reason that math has defined precedence (and even omits multiplication signs entirely in many places), programming languages in some domains will choose to do the same. It’s not a problem if you want to create a language that does not do this, but I think it is a problem if you want to ban others from doing it.

tsimionescu 3y ago
Algebra only really has defined precedence between multiplication and addition/subtraction. In all other cases, even division, there is either a non-linear textual representation, or parantheses are required. You have fractions, exponents, radical signs, various signs which appear only at the beginning of an expression (sigma, integral, lim) etc. Even multiplication is often distinguished more by the shape of the text than by actual precedence rules, once you leave basic arithmetic - expressions like "1 - 3xy + 2y²" make the order of operations obvious from text layout, which is why they are preferred over "1 - 3 × x × y + 2 × y ^ 2", which no mathematician ever writes.
- sokoloff 3y ago
  Exponentiation also has defined precedence, does it not? (Everyone who has passed algebra agrees that y is squared before being multiplied by 2 in your example.)
  - tsimionescu 3y ago
    You can view that as precedence, but I think it's more correct to say that exponentiation binds to the single symbol it is attached to. When you write x² + 2, I don't think it's operator precedence that makes it clear this is not equal to x ^ 4. Similarly, in the following expression: x _ + 2 2 I don't think it's precedence that makes it clear you first divide by 2 and then add 2 to the result.
    - sokoloff 3y ago
      Alternatively, perhaps what you're observing is simply the graphical representation of the underlying mathematical precedence rules. (Obviously, over hundreds of years of symbolic math, the notation and precedence has co-evolved, with precedence probably generally, well, preceding notation.) y = x / 3 + 2 y = 2 + x / 3 y = x/3 + 2 We all agree those are the same, despite a lack of an any cues in the first two. That suggests to me that there is a defined precedence for division vs addition in math. (So much so that it doesn't even seem like a controversial statement to make.)

lifthrasiir 3y ago

Some operator precedences are way more reasonable than others, and those between arithmetic operators are good examples. What we actually need is a partial order of operator precedences: you can have `1 * 2 + 3` or `full_name ?? first_name ++ " " ++ last_name` but not necessarily `1 * 2 & 3` because that combination of operators is uncommon and a parenthesis should be preferred instead of an arbitrary total order.

zarzavat 3y ago

Should `x == 1 or y == 3` be a syntax error? Because that’s operator precedence too.

kragen 3y ago
that's certainly a plausible position; in lisp (or = x 1 = y 3) is generally an error; even if it's not an error it doesn't mean what you intend it to. having to write (x == 1) || (y == 3), similar analogous to the code you'd write in lisp, would be only a minor burden in c, x == 1 || y == 3 works fine, but unfortunately the bitwise operators have the wrong precedence; x & 2 == 2 is parsed as x & (2 == 2), which is never what you meant. so even the best software designers have made terrible blunders in precedence design math formulas are a bigger issue; 3*x**2 + x/2 + 1 is a lot better than the fully parenthesized version
- zarzavat 3y ago
  There are of course operations with unclear precedence relationships and it’s completely reasonable to want to force parentheses when composing those operations. However, there are also operations with crystal clear precedence relationships, such as logical conjunction and comparison, and in that case it has to be asked what exactly would the parentheses be there for? In lisp the answer is: to enable syntactic homogeneity and to enable macros. But in other languages like Python that don’t have sexpr based syntax, parenthesizing everything would just be pointlessly unreadable.
  - kragen 3y ago
    it isn't crystal clear to everyone, smart guy, it's only clear if you're familiar with it
ctrw 3y ago
That is type inference actually.
boxed 3y ago
yea it should

frud 3y ago

For basically forever compilers and languages have been designed with a total ordering on operator precedences. The Yacc compiler generator tool maps operator precedence to integers, as do most handwritten compiler parsers. A total ordering has a definite answer to the question "is x greater than, equal to, or less than y?" for all x and y. A partial ordering will answer "I don't know" for some x and y. It's quite possible to implement operator precedence using a partial ordering. When the parser has to resolve precedence between two operators and their relationship is not defined, throw an "ambiguous precedence" error. You can implement the partial ordering by putting all the operators into a DAG of sets of operators. If two operators are in the same set, they have equal precedence. If there is a path through the DAG from one operator to the other, that defines the precedence relation. Else there is no relation. Say "*" is defined to have a higher precedence than "+", and they both have an undefined precedence relation with "&". Then "1 + 2 * 3" should compile into "1 + (2*3)", but "1 + 2 & 3" should throw an "ambiguous precedence" syntax error.

adrian_b 3y ago

The lack of operator precedence has no relationship with the mandatory use of parentheses. For example the APL syntax for expressions, which I prefer, is that there is no operator precedence. The operands are associated to operators strictly from the right to the left, regardless which operators or functions are used, which is a much wiser choice than the reverse traditional order of evaluation. No parentheses are used, except when they are needed to modify the default evaluation order.

samatman 3y ago

That would get really annoying. Not in expressions like 1 + 3 * 6. Personally, I include the parentheses anyway, as a matter of style, and would write 1 + (3 * 6). But in expressions like i + 3 > 4 / n? No thank you, (i + 3) > (4 / n) would drive me up a wall. Ymmv.

recursivedoubts 3y ago

preach king https://hyperscript.org https://hyperscript.org doesn’t allow mixing different infix operators w/o parentheses