<p>I’m designing a language which uses Prefix (Polish) notation when applying functions. However, I’ve run into a problem: I’m not sure how to distinguish between function calls and variable references, since <code>add a b</code> can be parsed as either <code>add(a, b)</code> or <code>add(a(b))</code>.</p>
<p>One solution I thought of is requiring variables holding functions to start with a lowercase letter and have regular variables start with an uppercase letter, or a similar solution. Functions in my language are all lambdas, which can either have named arguments or just state how many arguments they take and use <code>$n</code> to refer to the nth arg. The issue with my proposed solution is that it doesn’t really work with the latter syntax for defining functions. I also can’t just rely on the function’s arity (how many arguments it takes) because with the latter syntax, whatever arguments were passed to the function are implicitly passed down to whatever functions are called with too few parameters (e.g. <code>{* 2} 5</code> becomes <code>* 2 5</code>)</p>
<p>Do you have any ideas as to how I might get around this? If there is a good solution in an existing language, that would be very helpful. I don’t want to bloat my syntax too much, but I’d rather have verbose but consistent code than concise but confusing.</p>

<syntax><language-design><functions>
How can I get around ambiguity with prefix notation?
<h1>Optional parens, but require commas</h1>
<p>This is what CoffeeScript does:</p>
<pre class="lang-coffee prettyprint-override"><code>foo bar baz   # JS: foo(bar(baz))
foo bar, baz  # JS: foo(bar, baz)
(foo bar) baz # JS: foo(bar)(baz)
</code></pre>
<p>Of course, this doesn’t work for four or more terms:</p>
<pre class="lang-coffee prettyprint-override"><code>foo bar baz, qux
# Is this foo(bar(baz), qux) or foo(bar(baz, qux))?
# CoffeeScript goes with the latter; the former requires parens:
foo bar(baz), qux
</code></pre>

CC BY-SA 4.0
2023-05-23T14:11:59.330Z
2023-05-23T14:11:59.330Z
Bbrk24
CC BY-SA 4.0
2023-05-23T14:34:05.270Z
I like this idea of doing it, but I’m accepting the answer of the Lisp syntax because it is pretty established and easy to parse in your mind in comparison to CoffeeScript’s approach.
Jacob
<p>Polish notation ─ and reverse Polish notation ─ can only be unambiguous if the arity of every term is known by the parser. So <code>add a b</code> would be parsed as <code>a</code> and <code>b</code> (each of zero arity) being the arguments to the function <code>add</code> (of arity 2). Even so, this can make the language harder to read by humans, because it also requires the human to know the arity of each term in order to determine the program's meaning.</p>
<p>The only other way to resolve ambiguity ─ and this applies whether you just want to make the language more readable to humans, or you want terms to have dynamic arities (e.g. user-defined functions) ─ is to simply define in the language specification which of the two meanings an otherwise-ambiguous term has. For example, you can say that <code>add a b</code> <em>always</em> means <code>a</code> and <code>b</code> are the arguments to <code>add</code>, and provide a different syntax for writing it the other way. Typically, that means you use brackets. This is how functional languages like Haskell or F# work.</p>
<p>You mention in the question that you can't rely on using the arity of a term to parse it, because you want to support partial application. This isn't really a problem, though. You can have the parser know the arity of each term, but then if fewer terms are provided, the parser just consumes fewer terms and the function is partially-applied.</p>

CC BY-SA 4.0
2023-05-23T14:11:37.153Z
2023-05-23T14:11:37.153Z
kaya3
CC BY-SA 4.0
2023-05-23T14:27:56.897Z
Good point about this still being possible with partial application, +1. But I think knowing the arity of the function at parse time will be too complicated with higher-order functions.
Jacob
CC BY-SA 4.0
2023-05-23T14:29:37.427Z
@Jacob Higher-order functions are still possible if their types are declared before they're used. The issue is that the parser needs to resolve names at parse-time, but it already does if any user-defined functions are involved.
kaya3
CC BY-SA 4.0
2023-05-23T14:35:24.997Z
That’s true, but I’m not yet sure whether this language will be statically or dynamically typed.
Jacob
CC BY-SA 4.0
2023-05-23T18:46:14.620Z
For an example of a statically typed language whose parser uses types to determine how many arguments each function takes, see [Husk](https://github.com/barbuz/Husk) (it's a really fun golflang)
user
<h1>Explicit Parentheses around arguments</h1>
<p>This is how most languages with prefix functions does it (and the core of Lisps):</p>
<pre class="lang-c prettyprint-override"><code>add(a b)
add(a(b))
{* 2}(5)
</code></pre>
<pre class="lang-lisp prettyprint-override"><code>(add a b)
(add (a b))
({* 2} 5)
</code></pre>

CC BY-SA 4.0
2023-05-23T14:03:03.900Z
2023-05-23T14:08:26.430Z
2023-05-23T14:08:26.430Z
bigyihsuan
CC BY-SA 4.0
2023-05-23T14:29:42.710Z
Accepting this answer because it shows an established syntax adding little overhead in most cases.
Jacob
# How can I get around ambiguity with prefix notation?
Posted by: username_0 on 2023-05-23
I’m designing a language which uses Prefix (Polish) notation when applying functions. However, I’ve run into a problem: I’m not sure how to distinguish between function calls and variable references, since `add a b` can be parsed as either `add(a, b)` or `add(a(b))`.

One solution I thought of is requiring variables holding functions to start with a lowercase letter and have regular variables start with an uppercase letter, or a similar solution. Functions in my language are all lambdas, which can either have named arguments or just state how many arguments they take and use `$n` to refer to the nth arg. The issue with my proposed solution is that it doesn’t really work with the latter syntax for defining functions. I also can’t just rely on the function’s arity (how many arguments it takes) because with the latter syntax, whatever arguments were passed to the function are implicitly passed down to whatever functions are called with too few parameters (e.g. `{* 2} 5` becomes `* 2 5`)

Do you have any ideas as to how I might get around this? If there is a good solution in an existing language, that would be very helpful. I don’t want to bloat my syntax too much, but I’d rather have verbose but consistent code than concise but confusing.
**Tags:** syntax language-design functions
---
## 3 answers
### Answer by username_4 on 2023-05-23. Score: 4 | Accepted answer
Explicit Parentheses around arguments
This is how most languages with prefix functions does it (and the core of Lisps):
add(a b)
add(a(b))
{* 2}(5)

(add a b)
(add (a b))
({* 2} 5)
> **Comments:**
> **username_0** (2023-05-23): Accepting this answer because it shows an established syntax adding little overhead in most cases.  
---
### Answer by username_1 on 2023-05-23. Score: 4
Optional parens, but require commas
This is what CoffeeScript does:
foo bar baz   # JS: foo(bar(baz))
foo bar, baz  # JS: foo(bar, baz)
(foo bar) baz # JS: foo(bar)(baz)

Of course, this doesn’t work for four or more terms:
foo bar baz, qux
# Is this foo(bar(baz), qux) or foo(bar(baz, qux))?
# CoffeeScript goes with the latter; the former requires parens:
foo bar(baz), qux
> **Comments:**
> **username_0** (2023-05-23): I like this idea of doing it, but I’m accepting the answer of the Lisp syntax because it is pretty established and easy to parse in your mind in comparison to CoffeeScript’s approach.  
---
### Answer by username_2 on 2023-05-23. Score: 4
Polish notation ─ and reverse Polish notation ─ can only be unambiguous if the arity of every term is known by the parser. So `add a b` would be parsed as `a` and `b` (each of zero arity) being the arguments to the function `add` (of arity 2). Even so, this can make the language harder to read by humans, because it also requires the human to know the arity of each term in order to determine the program's meaning.

The only other way to resolve ambiguity ─ and this applies whether you just want to make the language more readable to humans, or you want terms to have dynamic arities (e.g. user-defined functions) ─ is to simply define in the language specification which of the two meanings an otherwise-ambiguous term has. For example, you can say that `add a b` *always* means `a` and `b` are the arguments to `add`, and provide a different syntax for writing it the other way. Typically, that means you use brackets. This is how functional languages like Haskell or F# work.

You mention in the question that you can't rely on using the arity of a term to parse it, because you want to support partial application. This isn't really a problem, though. You can have the parser know the arity of each term, but then if fewer terms are provided, the parser just consumes fewer terms and the function is partially-applied.
> **Comments:**
> **username_0** (2023-05-23): Good point about this still being possible with partial application, +1. But I think knowing the arity of the function at parse time will be too complicated with higher-order functions.  
> **username_2** (2023-05-23): @Jacob Higher-order functions are still possible if their types are declared before they're used. The issue is that the parser needs to resolve names at parse-time, but it already does if any user-defined functions are involved.  
> **username_0** (2023-05-23): That’s true, but I’m not yet sure whether this language will be statically or dynamically typed.  
> **username_3** (2023-05-23): For an example of a statically typed language whose parser uses types to determine how many arguments each function takes, see [Husk](https://github.com/barbuz/Husk) (it's a really fun golflang)  
---
