<p>How might one go about building a parser  that can distinguish custom operators in prefix, infix or postfix positions.</p>
<p>For example:</p>
<pre><code># Hypothetical operator
@postfix(Precedence.Not)
let ~ = fn(a) = ...

@infixleft(Precedence.Addition)
let ~^ = fn(a, b) = ...

@prefix(Precedence.Not)
let ^ = fn(a) = ...
</code></pre>
<p>How can a parser distinguish <code>a~^b</code> deterministically?</p>
<p>Is it <code>~^(a, b)</code> or <code>~(a)(^(b))</code> where a is a single argument function?</p>

<syntax><language-design><parsing><operators><operator-overloading>
How to distinguish custom operators from each other?
CC BY-SA 4.0
2023-05-17T19:16:41.450Z
One option is to just  have infix operators
Seggan
CC BY-SA 4.0
2023-05-19T19:31:10.370Z
This is, by definition, a syntactic ambiguity.
ice1000
<p>An easy solution is to require spaces between operators. Alternatively, you could enforce a policy that operators are parsed greedily left-to-right, for example, and then make it the programmer's responsibility to ensure unambiguity</p>

CC BY-SA 4.0
2023-05-17T18:53:18.533Z
2023-05-17T18:53:18.533Z
abel1502
CC BY-SA 4.0
2023-05-17T18:57:35.510Z
I fear if I just force spaces in between it might look weird when there are multiple prefix or postfix operators chained. Like: `a * - ~| ^ b` and leaves amguity in determining which one in the chain is an infix.
kaiserthe13th
CC BY-SA 4.0
2023-05-17T19:02:48.583Z
@kaiserthe13th Personally I think allowing arbitrary custom operators is almost guaranteed to cause confusion and ambiguity. Even if the language always specifies a specific interpretation to be correct, it's still very easy to get confused and assume another interpretation. One thing that could help in this regard is a smart syntax highlighting plugin that would clearly outline the correct interpretation
abel1502
CC BY-SA 4.0
2023-05-17T20:45:54.217Z
@kaiserthe13th Requiring spaces between operators is a pretty common solution for languages with custom operators, and it's a small sacrifice to make (IMO). Also, programmers will usually put spaces around operators anyway
user
CC BY-SA 4.0
2023-05-18T11:21:23.373Z
If you don't require spaces, then declaring new operators could break existing code.
Unrelated String
# How to distinguish custom operators from each other?
Posted by: username_0 on 2023-05-17
How might one go about building a parser  that can distinguish custom operators in prefix, infix or postfix positions.
For example:
# Hypothetical operator
@postfix(Precedence.Not)
let ~ = fn(a) = ...

@infixleft(Precedence.Addition)
let ~^ = fn(a, b) = ...

@prefix(Precedence.Not)
let ^ = fn(a) = ...

How can a parser distinguish a~^b deterministically?
Is it ~^(a, b) or ~(a)(^(b)) where a is a single argument function?
**Tags:** syntax language-design parsing operators operator-overloading
> **Comments:**
> **username_1**: One option is to just  have infix operators  
> **username_2**: This is, by definition, a syntactic ambiguity.  
---
## 1 answers
### Answer by username_3 on 2023-05-17. Score: 5 | Accepted answer
An easy solution is to require spaces between operators. Alternatively, you could enforce a policy that operators are parsed greedily left-to-right, for example, and then make it the programmer's responsibility to ensure unambiguity
> **Comments:**
> **username_0** (2023-05-17): I fear if I just force spaces in between it might look weird when there are multiple prefix or postfix operators chained. Like: `a * - ~| ^ b` and leaves amguity in determining which one in the chain is an infix.  
> **username_3** (2023-05-17): @kaiserthe13th Personally I think allowing arbitrary custom operators is almost guaranteed to cause confusion and ambiguity. Even if the language always specifies a specific interpretation to be correct, it's still very easy to get confused and assume another interpretation. One thing that could help in this regard is a smart syntax highlighting plugin that would clearly outline the correct interpretation  
> **username_4** (2023-05-17): @kaiserthe13th Requiring spaces between operators is a pretty common solution for languages with custom operators, and it's a small sacrifice to make (IMO). Also, programmers will usually put spaces around operators anyway  
> **username_5** (2023-05-18): If you don't require spaces, then declaring new operators could break existing code.  
---
