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.

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

    a (*) b + c

    a * (b + c)

    (a * b) + c

    a + b * c << d

    (a + (b * c)) << d

    a + b (*) c << d

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

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

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

  ((a & b) $ c) @ d

  (a & b) $ (c @ d)

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

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...

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

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.

> 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.

And yet, this is the top entry on HN right now?! How does that happen??

The examples at the end show that it's syntax for "parse such that this expression is not grouped". Essentially I guess this could be modelled as an operator `(_+_)` for every existing operator `_+_`, which has its binding precedence negated.

I think ungrouping make sense if you consider reverse parentheses as a syntactic construct added to the language, and not replacing the existing parentheses.

For instance, using "] e [" as the notation for reverse parentheses around expression e, the second line showing reverse parenthese simplification, third line showing the grouping after parsing, and the fourth line using postfix notation:

A + B * (C + D) * (E + F)

=> A + B * (C + D) * (E + F)

=> (A + (B * (C + D) * (E + F)))

=> A B C D + E F + * * +

A + ] B * (C + D) [ * (E + F)

=> A + B * C + D * (E + F)

=> ((A + (B * C)) + (D * (E + F)))

=> A B C * + D E F * + +

So what ungrouping would mean is to undo the grouping done by regular parentheses.

However, this is not what is proposed later in the article.

Possibilities include reversing the priority inside the reverse parentheses, or lowering the priority wrt the rest of the expression.

I stumbled on this:

https://lobste.rs/s/qoqfwz/inverse_parentheses#c_n5z77w

which should provide the answer.

I'm not sure I'm following but I think what he means is that if normal parenthesis around an addition mean this addition must precede multiplication, these anti-parenthesis around a multiplication have to make addition take place before it.

I think surrounding the operand would make slightly more sense, as in 1 + 2 (*) 3 as if it's a "delayed form" of the operation that it represents.

Same.

That said if you try to use that with ordinary parentheses usage it would get ambiguous as soon as you nest them

Do you really like Lisp?

It's not just brilliant, it's earth-shattering.

llm generated comment

could this be the origin of lisp and ML family list notation ?

Same in Safari. It has something to do with the

  :root {
    […]
    overflow: hidden scroll;
    container-type: size;
    […]
  }

Cannot scroll on Safari on macOS, either. What also doesn't work is making the font smaller / larger.

Splendid. Someone found a way to break Browser Scrolling. (Firefox 115.16 for Win7)

Well done.