Inverse Parentheses
Key topics
The intriguing concept of "inverse parentheses" has sparked a lively debate, with some commenters questioning the practicality of introducing a new syntax to "ungroup" operands. While some, like Smaug123, see it as a potential operator for parsing expressions in a non-grouped manner, others, such as chrisweekly, dismiss the idea as inane due to potential visual ambiguities when nesting. Meanwhile, a more pressing issue arose when several users reported being unable to scroll through the author's webpage due to a CSS-related bug. As the discussion unfolds, it becomes clear that the idea of inverse parentheses is as much about challenging conventional programming syntax as it is about sparking creative thinking.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
20m
Peak period
65
Day 1
Avg / period
33
Based on 66 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 3:29 AM EST
19 days ago
Step 01 - 02First comment
Dec 22, 2025 at 3:48 AM EST
20m after posting
Step 02 - 03Peak activity
65 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 2, 2026 at 4:24 AM EST
8 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Well done.
Since this doesn't exist in practice, shouldn't the article author first explain what they mean by that?
> 1 + )2 * 3(
(1 + 2) * 3
That said if you try to use that with ordinary parentheses usage it would get ambiguous as soon as you nest them
Two comments here which elaborate why this is ill defined:
https://news.ycombinator.com/item?id=46352560
https://news.ycombinator.com/item?id=46352697
I love the twist: reversing the friendly levels gives you a classic parser, and it opens up crazy experiments like whitespace weakening. Have you tested it on non-arithmetic ops (logical/bitwise) or more complex expressions like ((()))?
https://lobste.rs/s/qoqfwz/inverse_parentheses#c_n5z77w
which should provide the answer.
For instance, using "] e [" as the notation for reverse parentheses around expression e :
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.
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
((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.
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).
;)
Now all you need are the opening and closing parentheses at the start and end, and we're back to normal.
A real Wesley Crusher moment.
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
I recommend https://www.hpmuseum.org/ for more details.
Gerald Jay "Jerry" Sussman from Scheme and SICP fame (and others) would tell you there's also the prefix notation. "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.
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.
The more I think about this, the less sense it makes...
[1] https://en.cppreference.com/w/c/language/operator_precedence...
Instead of ordinary brackets, one can also use the dot notation. I think it was used in Principia Mathematica or slightly later:
would be Essentially, the more dots you add, the stronger the grouping operator is binding.However, this is only a replacement for ordinary parentheses, not for these "reverse" ones discussed here. Maybe for reverse, one could use groups of little circles instead of dots: °, °°, °°°, etc.
What if you need to nest parentheses? Then you use more dots. A double dot (:) is like a single dot, but stronger. For example, we write ((1+2)×3)+4 as 1+2 . × 3 : + 4, and the double dot isolates the entire 1+2 . × 3 expression into a single sub-formula to which the +4 applies.²
A dot can be thought of as a pair of parentheses, “) (”, with implicit parentheses at the beginning and end as needed.
In general the “direction” rule for interpreting a formula ‘A.B’ will be to first indicate that the center dot “works both backwards and forwards” to give first ‘A).(B’, and then the opening and closing parentheses are added to yield ‘(A).(B)’. The extra set of pairs of parentheses is then reduced to the formula (A.B).³
So perhaps one way of thinking about it is that more dots indicates more separation.
¹ https://plato.stanford.edu/entries/pm-notation/dots.html
² https://blog.plover.com/math/PM.html
³ https://plato.stanford.edu/entries/pm-notation/dots.html
See also https://plato.stanford.edu/entries/pm-notation/index.html
And I do, I bounced off it the first time long ago, and really took to it the second go around, its been my daily driver at home and work for some years now- it brings me great joy.
For example,
becomes and then we add the missing parentheses and it becomes which seems to achieve a similar goal and is pretty unambiguous.System: How about “Inverse Parentheses”? We can write the entire article without ever defining what it means. Nerds will be unable to resist.
Clearly, this was the worst possible time for me to come across this brain damaging essay. I really can’t afford it! But adding a symmetry to precedence control screams out to be treated seriously. Zeus, help me.
1 + (2 * 3) forces 2 * 3 to happen first.
Without them, operator precedence decides. The post asks a deliberately strange question:
What if parentheses did the opposite — instead of grouping things tighter, they made them bind less tightly?