3

I would think it would be a massive breaking change if something like this were to happen on a widely deployed language like C/C++, but maybe it has happened in the past.

Bonus related question: How much should one rely on operator precedence when coding something? Should I save on those ()s?

migrated from cs.stackexchange.com Apr 4 '16 at 23:11

This question came from our site for students, researchers and practitioners of computer science.

  • 1
    Major languages have a more or less fixed syntax, and are usually backward compatible. – Yuval Filmus Mar 20 '16 at 22:05
  • 2
    This seems to be a combination of the history of programming languages and programming advice; I don't think either of them is on-topic. (The history of programming languages in general might be on-topic but this seems to be asking for a trivia-quiz-style fact, rather than anything conceptual.) – David Richerby Mar 21 '16 at 2:40
  • I'm not asking for a trivia-quiz-style fact. – almosnow Mar 21 '16 at 3:07
3

All languages are mostly backward compatible, adding keywords, changing syntax, standarizing undefined behaviours or obvious flaws.
The precedence itself is quite safe, but there are languages that break it, or are begging for years to be changed (like JavaScript).

C and C++ are backwards compatible - there were no change of rules and operator precedence is reliable, compilers on the other hand were not always standards compliant, but this does not touch precedence.

There are different things to consider: saving () is not really a save, but maintains readability without memorizing operator precedence (which is not a big deal, but it saves a second looking at code and saves more when there are more people involved). You can check that the compiler will produce binary identical output (if the parentheses are superfluous).

But there are situations where something is not regulated by the standard, e.g. gives undefined / compiler dependent results; on this you can never rely.
a[i] = ++i;, i = ++i + i++, f(++i, ++i)
Or architecture dependent like: i << 33 for unsigned int (Intel vs ARM gives different results).

For Example Python 3 is not backward compatible with Python 2.
PHP 7 gives backward incompatibility with evaluation of indirect expressions (it was evaluated in mixed manner, now this is strictly left-to-right).
There are more languages that are less popular and broke backwards compatibility, even with operators precedence (if something was flawed, well why not?, and something made them "minor" not "major" languages, right?).
Another example is Fortran, it broke some syntax.

  • A little hint, automatic string coercion, broken typeof, built-in sort uses strings etc. – EvilJS Mar 21 '16 at 3:15
  • Oh ok, I meant, regarding operator precedence. About those, yeah typeof null == 'object' is funny at best hehe – almosnow Mar 21 '16 at 3:43
  • There is one minor difference: in C, the conditional operator has higher precedence than assignment: a ? b : c = d is (a ? b : c) = d (which is a syntax error because a ?:-expression is not an lvalue), while in C++ they have the same precedence and right associativity, so a ? b : c = d is a ? b : (c = d). – Jon Purdy Apr 5 '16 at 5:42
  • Back sufficiently far in C history, the <op>= shortcut was written as =<op>, but that changed in, I think, the mid-to-late 70s. – Vatine Apr 5 '16 at 12:06
  • @JonPurdy I do not fully understand why do you compare C with C++? – Evil Apr 5 '16 at 17:03
0

Languages tend to stay stable in how their grammar is defined.

If they changed it too much:

  • Written programs won't compile/change behaviour
  • Programmers would have to completely relearn the language each time its updated
  • Compilers/Interpreters would be much more expensive to write as each language-version needs a separate front-end.
  • Businesses would avoid the elevated costs of change, and more of them would not adopt newer, and more secure technologies.

This would drive Programmers to only use more stable languages. This is why so many of us write in old languages. These are the stable languages.

However a language for expressing programs is useless without something that comprehends it. Unfortunately the only languages on the planet that are comprehended by executive entities (aka. processors) are machine languages and you really do not want to program anything in these. Also they are some of the most stable languages on the planet, modern processors in some processor families can still faithfully execute code written three decades ago.

To bridge the gap between nice programming languages and machine languages there are compilers and interpreters.

  1. These are programs,
  2. Programs are written by humans,
  3. Which means they can contain errors.
  4. Errors can change behaviours,
  5. Behaviours affect the written machine code,
  6. Which means the machine code can be essentially different from the programming code.
  7. So it is possible for code to be compiled/interpreted differently by different compilers/interpreters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy