Change the precedence of “/” to something between “addition” and “syntax”?

Internals & Design
1

I see, the convenience of maths expressions is important in Julia. The problem with current precedence of “/” is, it is often considered as the fractional slash and people use it only once in a fraction, e.g. “1/(2*3*4)” instead of “1/2/3/4”.
If the precedence of “/” were lower than “addition” and higher than “syntax”, the same expression would be written as “1/2*3*4”, which is more visually convenient.
Examples:

x₍1₎=(-b+√(b^2-4a*c))/2a
x₍1₎=-b+√(b^2-4a*c)/2a

2tan(α)/(1-tan(α)^2)
2tan(α)/1-tan(α)^2

π/2-(α+β)/2
(π/2)-(α+β/2)

a*x^3+b*x^2+c*x+d
a*x^3+b*x^2+c*x+d

Before, the parentheses need to be typed if there are “+” or “-” in the numerator and denominator or “*” in the denominator; after, the parentheses need to be typed if it is a fraction.
What do you think?

2

Order of operations is widely understood with division having the same precedence as multiplication, so I think it would be very confusing (and a massively breaking change).

12 Likes
3

Without having any particular views on the merits of the suggestion, surely this is hugely breaking and could only be considered for 2.0 if at all?

3 Likes
4
5 Likes
5

Interpreting this as having the -b in the numerator would seem very surprising. On paper this would be unambiguous and match what the computer now thinks.

Not mentioned above, the one concession in this direction is that multiplication 2a has higher precedence than 2*a right now. If you write out all the operators, you would need more brackets: -b + sqrt(b^2-4*a*c)/(2*a)

5 Likes
6

@Sukera has given the correct answer. However, I don’t anticipate your suggestion will find acceptance for Julia 2.0 either, nor for any serious programming language.

This is one of those cases where you hope the computer will “do what I want, not what I say.” Broadly, that sort of situation cannot be resolved in a manner that is unambiguous and will satisfy everyone, and instead you just have a complicated ruleset that confuses everyone and makes nobody happy in the end. Giving division lower operator precedence than addition will confuse not only people coming from other programming languages, but mathematicians too.

In written math, we have the benefit of being able to write both inline division, e.g.:

1/2+3/4

as well as block division, e.g.:

\frac{1+2}{3+4}

The ability to write fractions in block form saves us a lot of parentheses! But in cases where you cannot typeset block division, and must put an equation inline in your text, that second expression must (by the broadly accepted rules of mathematics!) be (1+2)/(3+4).

Unfortunately, in programming (i.e., using a plaintext editor) we simply don’t have the ability to express block equations; everything must be in their inline forms. Julia has made some exceptions to this for matrix building, but those cases seem comparatively doable, unambiguous, and worthwhile.

3 Likes
7

Right, this isn’t just a question of breaking with current Julia but also with essentially every other mainstream programming language. The time to debate this was 65 years ago.

12 Likes
8

First, I don’t know how you can represent everyone, including people who don’t know you and people you don’t know.
Second, in schools, we learned that “÷” means division, “%” means percentage, “=” means equal to. According to your speech, they are causing confusions in Julia and unacceptable.
We are making many mistakes in programming, and the mistakes around parentheses is one of the most common types. Why would people make such mistakes? Because of some rules that were determined by people in the early days. Languages in those days were flawed and few can survive till today.
In JSON, people have to write quotation marks over and over again. In YAML, that is avoided, which is one of the reasons to make it popular, and is still rejected by some people.
The solution is what I said, to recognize “/” as the fraction slash instead of the division sign. By doing so, every division is considered as a fraction. If there are other terms, use parentheses to clamp it and then type “+” or “-” to connect it to other terms.
It is clear that this change is not going to happen in Julia. I am not going to spend time here.

9

Sorry, I used the word “nobody” here in the rhetorical sense, not the strict mathematical sense to mean that \nexists(\textrm{anyone who would be happy}). The distribution of human preference is sufficiently wide that somebody, somewhere would be happy with it.

The problem is that people whose minds are trained on operator precedence as it is widely accepted by mathematicians (and anybody else who has spent too much of their life doing math, such as physicists and engineers) would not be happy. And those are the people who this language is trying to please!

3 Likes
10

Operator precedence is always an issue in languages which use it, i.e., almost all. Guess that most of them agree on addition, subtraction binding less strongly than division, multiplication binding less strongly than exponentiation.
The only languages I’m aware of which break with mathematical traditions are APL/J and Smalltalk. In both cases, notation is simplified by giving all operators the same precedence and either associating to the the right or left respectively. Yet other languages such as Lisp or Forth do not require precedence rule as prefix or postfix notation is unambiguous already. In any case, Rosetta code has an interesting list with the glorious details for a whole bunch of languages.

2 Likes
11

Also if you like alternative “convenience” just define a
@myprecedence macro that explicitly parenthesizes the way you want.

3 Likes
12

But. Why break a decades long almost universal convention, when the new way isn’t even better, but in fact worse?

x+y/2 meaning (x+y)/2 is really bad.

8 Likes
13

100_000%

2 Likes
14

To me Julia is in the perfect spot for this: a/2b==a/(2*b)≠a/2*b. This is exactly how I would write this when handwaving at a whiteboard, it coincides with how I pronounce the respective operations and it’s a really simple heuristic to internalize. I know this is an immediately rejected idea, but I’d like to extend gratitude and support for the fact.

4 Likes
15

Gotta love @bertschi, always adding perspective :wink:

Some commentary if I may.

I’m dating myself here, but back in my day (invoke Grandpa Simpson meme) when I was a script kiddy learning JavaScript and my IDE was Notepad, JSON would’ve been an amazing communication protocol. So it’s funny that there’s now debate of JSON vs YAML vs TOML vs etc… :sweat_smile:

You sound like you’re maybe in your early teens, which was how old I was when I learned JavaScript. It was a hugely fun experience, and programming has only gotten better since then. While I disagree strongly on the specific topic you’ve chosen to challenge, I like that you’re trying things and questioning things. I hope you continue, because that’s how deep knowledge is developed, and it’s how progress happens. And if I may, I think Julia is the best programming language in human history, so just learn it :wink:.

And like @dlakelan said, try making a macro that implements your preferred syntax! Who knows, maybe you’ll prove all us old farts wrong, and the future belongs to languages that give / lower precedence? I’m willing to bet against it on some pretty steep odds (I can explain my reasoning if you wish), but you never know if you never try and ultimately the test of time is what separates the signal from the noise.

2 Likes