Based on this comment (https://news.ycombinator.com/item?id=46352389), I think I understood the missing first paragraph:

If you have the expression 1+2*3 you have three elements with two operands. You need to choose a rule to pick one of them first.

In mathematics, the rule is "*/ then +-" and then from left to right. This means that usually first you do 2*3, then 1+.

But what if you do want to make 1+2 first?

There is another alternative, parenthesis. Those mean "do the thing inside first" so (1+2)*3 changes the precedence and now you do 1+2 first, then *3

The post is asking: with parenthesis you can increase the precedence of operations. What if you could decrease it?

Let's use «» as another operand (the blog uses parenthesis, but that makes it really confusing) this operand means "do the thing inside last". So the expression 1+«2*3» means "do 1+ first, then 2*3.

The issue is...this doesn't make sense, what the blog is really saying is to reduce the precedence of operators. Think the expression 1+2«*»3 or 1+2(*)3 and now the rule is "the parenthesized operators have one precedence less" so 1+2(*)3=(1+2)*3

▲ jeroen 9 hours ago | parent | next [-]

If we actually (as the title seems to imply) invert the parentheses, then for your example we get 1+2)*(3 .

Now all you need are the opening and closing parentheses at the start and end, and we're back to normal.

▲ sunir 5 hours ago | parent | next [-]

Thank you. I thought I was going crazy reading the article which doesn’t connect open and close parenthesis :: higher and lower precedence :: indent and outdent :: +1 and -1 and just flip it around to get the opposing polarity.

A real Wesley Crusher moment.

▲ swiftcoder 9 hours ago | parent | prev [-]

Yeah, that seems a much more robust formulation of the whole thing. Flip all parens and enclose the whole string in more parens.

	▲	chrisweekly 7 hours ago \| parent [-]
		that results in `(1+2)(3)` which is (as GP notes), equivalent to "normal", ie what we do today: `(1+2)3` Right?

▲ sebtron 10 hours ago | parent | prev | next [-]

This seems to be the best guess so far. But then I am wondering, how is

    a (*) b + c

Parsed then? The precedence of '* is bumped down, but does that mean it has now strictly lower precedence of '+', or the same? In the first case the operation is parsed as

    a * (b + c)

In the second case, the "left to right" rule takes over and we get

    (a * b) + c

And what happens when there are more than 2 priority groups Taking C has an example, we have that '' has higher precedence than '+' which has higher precedence than '<<' [1]. So
a + b * c << d
Means
(a + (b * c)) << d
Now I could use the "decrease precedence" operator you proposed (possibly proposed by the author?) and write
a + b (*) c << d
Which then bumps down the precedence of '' to... One level lower? Which means the same level of '+', or a level lower, i.e. a new precedence level between '+' and '<<'? Or maybe this operator should end up at the bottom of the precedence rank, i.e. lower than ','?

The more I think about this, the less sense it makes...

[1] https://en.cppreference.com/w/c/language/operator_precedence...

▲ qsort 10 hours ago | parent | prev | next [-]

I don't think that's even well-defined if you have arbitrary infix operators with arbitrary precedence and arbitrary associativity (think Haskell). If $, & and @ are operators in that order of precedence, all right-associatve. Using your notation, what is:

  a & << b $ c >> @ d

If $ is reduced below & but above @ then it's the same as:

  ((a & b) $ c) @ d

If it's reduced below both & and @ then it becomes:

  (a & b) $ (c @ d)

I think conceptualizing parentheses as "increase priority" is fundamentally not the correct abstraction, it's school brain in a way. They are a way to specify an arbitrary tree of expressions, and in that sense they're complete.

	▲	layer8 6 hours ago \| parent [-]
		Clearly we need left-associative and right-associative inverse parentheses. a & )b $ c) @ d would mean ((a & b) $ c) @ d. a & (b $ c( @ d would mean a & (b $ (c @ d)). Combining both, a & )b $ c( @ d would mean (a & b) $ (c @ d). ;)

▲ integricho 11 hours ago | parent | prev | next [-]

Thanks, this makes more sense, the blog post was written in a really confusing way.

▲ Smalltalker-80 10 hours ago | parent | prev | next [-]

Thanks indeed. Using a simple left-to-right evaluation is the most logical solution. You can reorder expressions to use less parentheses and make them easier to read. E.g.: Smalltalk :-). But this requires everyone un-learning their primary school maths of e.g. multiply-before-add, so it's not popular. Having hand-picked operator precedences complicates things further when you allow operator overloading and user defined operators. E.g. Swift has special keywords to specify precedence for these. Ick...

	▲	NetMageSCW 2 hours ago \| parent [-]
		APL uses a simple right to left order of evaluation :)

▲ yccs27 10 hours ago | parent | prev | next [-]

Thanks, writing it as 1+2(*)3 made it click for me.

Reminds me of the '$' operator in Haskell - it lowers the precedence of function application, basically being an opening parenthesis that's implicitly closed at the end of the line.

▲ astrobe_ 3 hours ago | parent | prev | next [-]

well I'll be that guy... If you're going to disturb the normal way of righting expressions, RPN or prefix notation (AKA Polish Notation) could be a better option. Both don't need parenthesis because they don't need precedence/priority rules - which are obviously a disadvantage of the infix notation.

The HP 48 famously took the bet of going against the mainstream notation. I wonder to what extent this is one of those "accidents of history".

RPN moreover simplifies parsing, as shown by the Forth language.

Prefix notation, as used by for instance Lisp, doesn't actually need parenthesis either; Lisp uses them because it allows extensions over basic operators and more generally "variadic" operators and functions (e.g. (+ 1 2 3 4)). Without this "fancy" feature, prefix notation is unambiguous as well: / + 1 2 3. [1]

On a side note, Smalltalk is one of the few languages that said "duck it", and require explicit parenthesis instead - which is IMO, not an insane approach when you see that for languages with 17 levels of priority like C, you end up putting parenthesis anyway as soon as the expression is not trivial "just to be sure" (e.g. because it mixes boolean operators, arithmetic operators and relational operators as in a & 0xF < b + 1).

[1] https://en.wikipedia.org/wiki/Polish_notation

	▲	NetMageSCW 2 hours ago \| parent [-]
		The HP 48 followed a couple of decades of HP calculators using RPN (hardly famous, just an evolution). HP’s first calculator used RPN. I recommend https://www.hpmuseum.org/ for more details.

▲ TacticalCoder 6 hours ago | parent | prev [-]

> There is another alternative, parenthesis.

Gerald Jay "Jerry" Sussman from Scheme and SICP fame (and others) would tell you there's also the prefix notation (but ofc only infix makes TFA valid: prefix or postfix makes it mostly moot). "3 x 4 x 7 x 19" only looks natural to us because we've been taught that notation as toddlers (well, ok, as young kids).

But "x 3 4 7 19" is just as valid (Minksy and having to understand someting in five different ways or you don't understand it etc.).

P.S: also your comment stinks of AI to me.