<p><sub>Sorry if I am not using the correct terminology here, I'll correct it if it turns out to be that way.</sub></p>
<p>Programming languages such as Python or Mathematica typically have function syntax implemented as <code>f(a,b)</code>, <code>f[a,b]</code> or something similar to that (of course for example when dealing with functions having more than one input).</p>
<p>However, with languages like Uiua, functions are usually implemented as <code>f a b</code>, for example this code which outputs the argument of a complex number <span class="math-container">$\arg(z)$</span> (in this case <span class="math-container">$\arg(2+i)$</span>):</p>
<pre><code>F ← ×¯i ₙe±ℂ∩
F 1 2
</code></pre>
<p>My question is, why implement it this way? Are there any benefits to doing it like so?</p>

<syntax><language-design>
Why implement function syntax as `f a b` or `f: a b` instead of `f(a,b)`?
CC BY-SA 4.0
2024-04-16T22:32:01.847Z
See [currying](https://en.wikipedia.org/wiki/Currying).
Dannyu NDos
CC BY-SA 4.0
2024-04-16T23:21:00.527Z
You don't need to reach for esoteric languages to find examples of this ─ most mainstream functional programming languages use this syntax for function application, and it's also common in shell languages to invoke commands with no parentheses around their arguments. See [here](https://rigaux.org/language-study/syntax-across-languages.html#FnctnFnctCall) for a partial list.
kaya3
CC BY-SA 4.0
2024-04-17T12:58:46.127Z
Stack-based languages like Uiua or Forth have a completely different motivation and underlying mechanism for this than functional languages.
Unrelated String
CC BY-SA 4.0
2024-04-17T14:03:19.380Z
@UnrelatedString Which is...?
Pablo H
CC BY-SA 4.0
2024-04-17T22:35:59.670Z
It's probably a legacy of Fortran. In Fortran, whitespace is insignificant, so you need some other punctuation to separate the function name from the arguments, and the arguments from each other. Parentheses and commas were natural choices.
Barmar
CC BY-SA 4.0
2024-04-17T22:36:14.667Z
Are you also interested in `f a` and `a f b` as e.g. in APL (Uiua's grandparent)?
Adám
CC BY-SA 4.0
2024-04-18T01:36:54.097Z
@Adám I will have to check it out sometime :)
CrSb0001
CC BY-SA 4.0
2024-04-18T17:39:50.083Z
This feels like the flip-side of this question https://langdev.stackexchange.com/questions/1372/why-do-many-programming-languages-use-parentheses-for-function-definitions?rq=1 Although that one didn't lead to particularly enlightening answers. Also closely related: https://langdev.stackexchange.com/questions/1015/how-can-i-get-around-ambiguity-with-prefix-notation And maybe also this: https://langdev.stackexchange.com/questions/2451/could-function-parameters-be-placed-inside-names
IMSoP
CC BY-SA 4.0
2024-04-18T18:52:41.700Z
@IMSoP No, neither of the linked questions that you said were closely related to mine actually answered my question. "Why do many programming languages use parenthesis `()` for function definitions and calls?" asks about why programming languages use () for function definitions/calls and "How can I get around ambiguity with prefix notation" asks about how to avoid ambiguity with function notation. My question about why languages might use `f a b` or `f: a b` instead of `f(a,b)`, as in what benefits are there to doing so.
CrSb0001
CC BY-SA 4.0
2024-04-18T19:13:15.590Z
@CrSb0001 I didn't say that they were duplicates, and don't need you to read their titles back to me. I just thought it was interesting to link together some related discussions.
IMSoP
CC BY-SA 4.0
2024-04-18T19:17:28.147Z
@IMSoP That's my bad, I misunderstood what you were saying.
CrSb0001
CC BY-SA 4.0
2024-04-24T12:02:19.457Z
@Barmar This question is not about why FORTRAN chose parentheses, it's about why _other_ languages chose _anything else_. There is however [a parallel question](https://langdev.stackexchange.com/q/1372/1769), which I have also written an answer for. I haven't seen any evidence that whitespace is relevant in the slightest, only that FORTRAN (and ALGOL 58) chose a syntax that closely resembled common mathematical notation.
IMSoP
<p>For <code>f a b</code> to represent a function call, you need some way to decide if it's <code>f(a, b)</code> or <code>f(a(b))</code> or some other nesting. Some types of language have definitions or equivalents of function that give a natural answer to that, and use this to <strong>optimise syntax for a common case</strong>.</p>
<hr />
<p><a href="https://en.wikipedia.org/wiki/Polish_notation" rel="noreferrer">Polish Notation</a>, eliminates the need for operator precedence rules <em>if</em> every function and operator has a fixed arity (number of operands or formal parameters). <strong>Stack-oriented languages</strong> such as Forth generally use <em>Reverse</em> Polish Notation, where values are placed on the stack as the program is read left to right, and an operator or function takes a fixed number of items from the stack, and places its result in their place.</p>
<p>In Reverse Polish Notation, <code>b a f</code> means &quot;put <code>b</code> and <code>a</code> on the stack, then run sub-routine <code>f</code>, which will take two arguments off the stack&quot;. In more common parenthesis style, that's equivalent to <code>f(a, b)</code> - &quot;run sub-routine <code>f</code> with arguments <code>a</code> and <code>b</code>&quot;.</p>
<p>Note that this makes <strong>nested function calls implicit, and thus concise</strong>: if <code>f</code> and <code>a</code> are both functions that require one input, <code>b a f</code> instead represents &quot;apply function <code>a</code> to argument <code>b</code>, then apply function <code>f</code> to the result&quot; - or in parenthesis style, <code>f(a(b))</code>.</p>
<p>Uiua, mentioned in the question, is described as <a href="https://www.uiua.org/docs/rtl" rel="noreferrer">&quot;<strong>stack-based</strong> but not stack-oriented&quot;</a>, and processes each line of input from right to left. I haven't look at the details, but this is roughly Polish Notation (without the &quot;Reverse&quot;).</p>
<p>In this case <code>f a b</code> is equivalent to &quot;run sub-routine <code>f</code> with arguments <code>b</code> and <code>a</code>&quot;, i.e. parenthesis-style <code>f(b, a)</code> or <code>f(a, b)</code>. Nesting is again implicit: if <code>a</code> is actually a function, <code>f a b</code> will instead mean &quot;apply function <code>a</code> to argument <code>b</code>, then apply function <code>f</code> to the result&quot; - or in parenthesis style, <code>f(a(b))</code>.</p>
<hr />
<p><strong>Functional programming languages</strong> such as Haskell make heavy use of <a href="https://en.wikipedia.org/wiki/Currying" rel="noreferrer">currying</a>, where a function with multiple parameters is decomposed into a series of single-parameter functions which &quot;partially apply&quot; the full operation. The syntax then treats <strong>applying a function to one operand as the default operation</strong>.</p>
<p>This makes it possible to read <code>f a b</code> as a series of applications from left to right: call function <code>f</code> with the single argument <code>a</code>, then call the resulting function with single argument <code>b</code>. In parenthesis style, that would be <code>f(a)(b)</code>.</p>
<p>Passing functions themselves as parameters to &quot;higher-order functions&quot; is not just allowed but common, so the above rule applies even if <code>a</code> is itself a function. If you wanted to <em>apply</em> function <code>a</code>, rather than passing it as an argument to <code>f</code>, you would use parentheses to change the precedence: <code>f (a b)</code> would be equivalent to parenthesis-style <code>f( a(b) )</code>.</p>
<hr />
<p>In <strong>command-based</strong> languages, such as shell scripting, most statements consist of a single command (equivalent to a function) and its arguments. <strong>Evaluating a command within a larger expression is treated as the exception, rather than the rule</strong>, so has to be specified explicitly</p>
<p>For example, <code>f a b</code> means &quot;run command <code>f</code> with literal arguments <code>'a'</code> and <code>'b'</code>&quot;, equivalent to parenthesis-style <code>f('a', 'b')</code>. In many Unix shells, you can write <code>f $(a b)</code> for &quot;run command <code>a</code> with literal argument <code>'b'</code>; then run command <code>f</code> with that result as its argument&quot; - equivalent to <code>f(a('b'))</code>.</p>
<p>Assembly languages are generally an extreme form of this, where statements <em>always</em> consist of a single operation and a fixed list of operands.</p>
<hr />
<p>Finally, in <strong>Lisp and its descendents</strong>, functions are executed by evaluating the first item of a list as a function name, and the remainder as the list for it to process. This &quot;<strong>homoiconicity</strong>&quot; (unification of source code and data) makes it easy to write powerful meta-programming facilities by manipulating lists of symbols before executing them.</p>
<p>So  <code>(f a b)</code> will be interpreted as &quot;execute function <code>f</code> with argument list <code>(a b)</code>&quot;; the equivalent in parenthesis notation would be <code>f(a, b)</code>.</p>
<p>Unlike in Polish notation, nesting is explicit: to represent &quot;apply function <code>a</code> to argument <code>b</code>, then apply function <code>f</code> to the result&quot;, you have to write <code>(f (a b))</code>. This leads to the frequently discussed fact that Lisp programs generally require more parentheses than those in other languages.</p>

CC BY-SA 4.0
2024-04-21T21:25:29.187Z
2024-04-22T10:53:02.183Z
2024-04-22T10:53:02.183Z
IMSoP
CC BY-SA 4.0
2024-04-21T21:44:23.080Z
Haskell makes heavy use of infix operators as well -- prefix is only used for unary operators.
Chris Dodd
CC BY-SA 4.0
2024-04-21T22:09:30.493Z
@ChrisDodd Fair point. Apparently, [infix operators can be used as prefix functions, and vice versa](https://wiki.haskell.org/Infix_operator), so the whole program _could_ be written in either style. I'm not sure where that leaves the logic of my answer.
IMSoP
CC BY-SA 4.0
2024-04-22T03:15:27.163Z
@ChrisDodd Thinking about it, I don't think Polish notation is particularly relevant to the Haskell example, so I've restructured my answer to not connect the two.
IMSoP
CC BY-SA 4.0
2024-04-22T04:52:13.087Z
It would be helpful if this answer were to go the extra step and say something about the actual *syntax*. So far it seems to talk about semantics, with the implications for syntax being easy to guess if you know the answer already. The **command-based** paragraph currently seems to be the strongest.
MisterMiyagi
CC BY-SA 4.0
2024-04-22T06:34:06.443Z
@MisterMiyagi I'm not sure what you mean. Do you mean there should be more examples, or more commentary on the examples, or...?
IMSoP
CC BY-SA 4.0
2024-04-22T08:11:26.233Z
@IMSoP I might be missing something here but the answer seems to barely discuss  *syntax* and especially the *why* of it. For example, the **Functional programming languages** paragraph mostly explains currying, and how parentheses can be used *given* the Haskell syntax - but it does not say *why* the syntax was chosen that way. There's a bit that can be inferred here - that the syntax is *useful* with currying - but that isn't spelled out. Likewise, that `f (a b)` isn't "the mathematical f(a,b)" is shown but not pointed out; [...]
MisterMiyagi
CC BY-SA 4.0
2024-04-22T08:11:57.290Z
[...] it's shown from the "if you want to do Y instead" angle, not the "it's not X" angle. IMO all the bits are there but not presented to address the question.
MisterMiyagi
CC BY-SA 4.0
2024-04-22T10:30:55.057Z
@MisterMiyagi I've added a bunch more details - possibly too much, to be honest, but [I didn't have time to write a shorter letter](https://quoteinvestigator.com/2012/04/28/shorter-letter/). Does that cover what you felt was missing? (I always find "why" questions difficult - ultimately, the answer to "why does Haskell look that way?" is "because the people who designed it made it look that way").
IMSoP
<p>Programming languages use simple juxtaposition (<code>f a</code>) for function application because it is the standard notation for function application that has been used for more than 100 years, before the first electronic computers or high-level programming languages existed.</p>
<p>When there are mulitple arguments or other expressions involved, you would need parentheses to disambiguate. For example, one would use <code>f(a + b)</code> to apply <code>f</code> to the result of <code>a+b</code>, while <code>f a + b</code> would instead apply <code>f</code> to <code>a</code> and then add <code>b</code> to the result. So the real question is &quot;why did languages start requiring parentheses for function application even when they are not needed for precedence/disambiguation?&quot;</p>
<p>This originated with FORTRAN, which had two features that interact to require the parentheses:</p>
<ul>
<li>Multi-character names are allowed for things, so something like <code>fab</code> would be a single symbol, and not series of symbols involving some function applications</li>
<li>Whitespace is completely insignificant and ignored, so <code>f a b</code> and <code>fab</code> are the same.</li>
</ul>
<p>This was then carried over into later languages, even when they made whitespace significant.</p>

CC BY-SA 4.0
2024-04-21T11:38:48.147Z
2024-04-25T02:34:23.133Z
2024-04-25T02:34:23.133Z
Chris Dodd
CC BY-SA 4.0
2024-04-21T13:28:50.780Z
The current top answer to [this related question](https://langdev.stackexchange.com/q/1372/1769) asserts exactly the opposite of your first paragraph: that `f(x)` is the most common mathematical notation. That certainly matches my (non-expert) experience: `f x` represents multiplication, not function application. Neither that answer nor this one backs the claim up very well, but Wikipedia attributes the parenthetical notation to Euler in 1734, citing [this textbook which is available on archive.org](https://archive.org/details/CALCULUS10THEDITIONRONLARSON/page/n41/mode/2up).
IMSoP
CC BY-SA 4.0
2024-04-21T16:19:10.070Z
There is some truth to your statement about juxtaposition, but note that `f a b` in maths is equivalent to `f(a(b))`, not `f(a, b)`. So if `a` and `b` are just real values, `a(b)` would be the product of `a` and `b`, and `f` is applied on that product.
G. Sliepen
CC BY-SA 4.0
2024-04-21T21:28:05.330Z
This answer is misleading. According to Cajori, "A History of Mathematical Notations", volume 2, paragraph 643, function notations both with and without parentheses are quite old: "The use of parentheses for [enclosing the variable of a function] occurs in Euler in 1734, who says, "Si $f(x/a + c)$ denotet functionem quamcunque ipsius $x/a + c$."... About the same time Clairaut designates a function of $x$ by $\Pi x$, $\Phi x$, or $\Delta x$, without using parentheses." Obviously, the notation with parentheses ended up becoming more popular in mathematics.
RobertR
CC BY-SA 4.0
2024-04-25T02:27:37.170Z
@RobertR: your quote from Cajori supports my position -- the parens are used to disambiguate when there are mulitple arguments or an expression to be gathered,  and not when using a simple function of one argument.
Chris Dodd
CC BY-SA 4.0
2024-04-25T07:07:07.890Z
@ChrisDodd Your answer says that juxtaposition, with *optional* parentheses, has been the standard function application notation for over 100 years, which isn't true. Different fields of math/CS have different standards that have evolved over time, but today the standard in most fields of math/CS is undeniably juxtaposition with *mandatory* parentheses. ...
RobertR
CC BY-SA 4.0
2024-04-25T07:07:20.813Z
... The Euler example in passage I quoted is misleading, because the expression in the parentheses is composite, but mathematicians in the 1700's *did* write function applications to a single variable with parentheses, and some even wrote applications to multiple variables *without* parentheses. E.g., here's the very next two sentences from the passage I previously quoted: "In 1747 D'Alembert marked functions of two variables $u$ and $s$ by the signs $\Delta u,s$, $\Gamma u,s$. In 1754 he says: "Soit $\varphi(z)$ une fonction de la variable $z$, ..."."
RobertR
CC BY-SA 4.0
2024-04-27T12:07:43.463Z
I wonder if there is a difference between different areas of mathematics, or different parts of the world, or some other reason why we're at odds here. I'm clearly not alone in thinking that a single-parameter function is written $f(x)$ rather than $fx$ or $f \ x$; but you seem very confident of the opposite. It would be really useful to have some context of where you have seen this.
IMSoP
# Why implement function syntax as `f a b` or `f: a b` instead of `f(a,b)`?
Posted by: username_0 on 2024-04-16
Sorry if I am not using the correct terminology here, I'll correct it if it turns out to be that way.
Programming languages such as Python or Mathematica typically have function syntax implemented as f(a,b), f[a,b] or something similar to that (of course for example when dealing with functions having more than one input).
However, with languages like Uiua, functions are usually implemented as f a b, for example this code which outputs the argument of a complex number $\arg(z)$ (in this case $\arg(2+i)$):
F ← ×¯i ₙe±ℂ∩
F 1 2

My question is, why implement it this way? Are there any benefits to doing it like so?
**Tags:** syntax language-design
> **Comments:**
> **username_1**: See [currying](https://en.wikipedia.org/wiki/Currying).  
> **username_2**: You don't need to reach for esoteric languages to find examples of this ─ most mainstream functional programming languages use this syntax for function application, and it's also common in shell languages to invoke commands with no parentheses around their arguments. See [here](https://rigaux.org/language-study/syntax-across-languages.html#FnctnFnctCall) for a partial list.  
> **username_3**: Stack-based languages like Uiua or Forth have a completely different motivation and underlying mechanism for this than functional languages.  
> **username_4**: @UnrelatedString Which is...?  
> **username_5**: It's probably a legacy of Fortran. In Fortran, whitespace is insignificant, so you need some other punctuation to separate the function name from the arguments, and the arguments from each other. Parentheses and commas were natural choices.  
> **username_6**: Are you also interested in `f a` and `a f b` as e.g. in APL (Uiua's grandparent)?  
> **username_0**: @Adám I will have to check it out sometime :)  
> **username_7**: This feels like the flip-side of this question https://langdev.stackexchange.com/questions/1372/why-do-many-programming-languages-use-parentheses-for-function-definitions?rq=1 Although that one didn't lead to particularly enlightening answers. Also closely related: https://langdev.stackexchange.com/questions/1015/how-can-i-get-around-ambiguity-with-prefix-notation And maybe also this: https://langdev.stackexchange.com/questions/2451/could-function-parameters-be-placed-inside-names  
> **username_0**: @IMSoP No, neither of the linked questions that you said were closely related to mine actually answered my question. "Why do many programming languages use parenthesis `()` for function definitions and calls?" asks about why programming languages use () for function definitions/calls and "How can I get around ambiguity with prefix notation" asks about how to avoid ambiguity with function notation. My question about why languages might use `f a b` or `f: a b` instead of `f(a,b)`, as in what benefits are there to doing so.  
> **username_7**: @CrSb0001 I didn't say that they were duplicates, and don't need you to read their titles back to me. I just thought it was interesting to link together some related discussions.  
> **username_0**: @IMSoP That's my bad, I misunderstood what you were saying.  
> **username_7**: @Barmar This question is not about why FORTRAN chose parentheses, it's about why _other_ languages chose _anything else_. There is however [a parallel question](https://langdev.stackexchange.com/q/1372/1769), which I have also written an answer for. I haven't seen any evidence that whitespace is relevant in the slightest, only that FORTRAN (and ALGOL 58) chose a syntax that closely resembled common mathematical notation.  
---
## 2 answers
### Answer by username_7 on 2024-04-21. Score: 9 | Accepted answer
For `f a b` to represent a function call, you need some way to decide if it's `f(a, b)` or `f(a(b))` or some other nesting. Some types of language have definitions or equivalents of function that give a natural answer to that, and use this to **optimise syntax for a common case**.

---

[Polish Notation](https://en.wikipedia.org/wiki/Polish_notation), eliminates the need for operator precedence rules *if* every function and operator has a fixed arity (number of operands or formal parameters). **Stack-oriented languages** such as Forth generally use *Reverse* Polish Notation, where values are placed on the stack as the program is read left to right, and an operator or function takes a fixed number of items from the stack, and places its result in their place.

In Reverse Polish Notation, `b a f` means "put `b` and `a` on the stack, then run sub-routine `f`, which will take two arguments off the stack". In more common parenthesis style, that's equivalent to `f(a, b)` - "run sub-routine `f` with arguments `a` and `b`".

Note that this makes **nested function calls implicit, and thus concise**: if `f` and `a` are both functions that require one input, `b a f` instead represents "apply function `a` to argument `b`, then apply function `f` to the result" - or in parenthesis style, `f(a(b))`.

Uiua, mentioned in the question, is described as ["**stack-based** but not stack-oriented"](https://www.uiua.org/docs/rtl), and processes each line of input from right to left. I haven't look at the details, but this is roughly Polish Notation (without the "Reverse").

In this case `f a b` is equivalent to "run sub-routine `f` with arguments `b` and `a`", i.e. parenthesis-style `f(b, a)` or `f(a, b)`. Nesting is again implicit: if `a` is actually a function, `f a b` will instead mean "apply function `a` to argument `b`, then apply function `f` to the result" - or in parenthesis style, `f(a(b))`.

---

**Functional programming languages** such as Haskell make heavy use of [currying](https://en.wikipedia.org/wiki/Currying), where a function with multiple parameters is decomposed into a series of single-parameter functions which "partially apply" the full operation. The syntax then treats **applying a function to one operand as the default operation**.

This makes it possible to read `f a b` as a series of applications from left to right: call function `f` with the single argument `a`, then call the resulting function with single argument `b`. In parenthesis style, that would be `f(a)(b)`.

Passing functions themselves as parameters to "higher-order functions" is not just allowed but common, so the above rule applies even if `a` is itself a function. If you wanted to *apply* function `a`, rather than passing it as an argument to `f`, you would use parentheses to change the precedence: `f (a b)` would be equivalent to parenthesis-style `f( a(b) )`.

---

In **command-based** languages, such as shell scripting, most statements consist of a single command (equivalent to a function) and its arguments. **Evaluating a command within a larger expression is treated as the exception, rather than the rule**, so has to be specified explicitly

For example, `f a b` means "run command `f` with literal arguments `'a'` and `'b'`", equivalent to parenthesis-style `f('a', 'b')`. In many Unix shells, you can write `f $(a b)` for "run command `a` with literal argument `'b'`; then run command `f` with that result as its argument" - equivalent to `f(a('b'))`.

Assembly languages are generally an extreme form of this, where statements *always* consist of a single operation and a fixed list of operands.

---

Finally, in **Lisp and its descendents**, functions are executed by evaluating the first item of a list as a function name, and the remainder as the list for it to process. This "**homoiconicity**" (unification of source code and data) makes it easy to write powerful meta-programming facilities by manipulating lists of symbols before executing them.

So `(f a b)` will be interpreted as "execute function `f` with argument list `(a b)`"; the equivalent in parenthesis notation would be `f(a, b)`.

Unlike in Polish notation, nesting is explicit: to represent "apply function `a` to argument `b`, then apply function `f` to the result", you have to write `(f (a b))`. This leads to the frequently discussed fact that Lisp programs generally require more parentheses than those in other languages.
> **Comments:**
> **username_8** (2024-04-21): Haskell makes heavy use of infix operators as well -- prefix is only used for unary operators.  
> **username_7** (2024-04-21): @ChrisDodd Fair point. Apparently, [infix operators can be used as prefix functions, and vice versa](https://wiki.haskell.org/Infix_operator), so the whole program _could_ be written in either style. I'm not sure where that leaves the logic of my answer.  
> **username_7** (2024-04-22): @ChrisDodd Thinking about it, I don't think Polish notation is particularly relevant to the Haskell example, so I've restructured my answer to not connect the two.  
> **username_9** (2024-04-22): It would be helpful if this answer were to go the extra step and say something about the actual *syntax*. So far it seems to talk about semantics, with the implications for syntax being easy to guess if you know the answer already. The **command-based** paragraph currently seems to be the strongest.  
> **username_7** (2024-04-22): @MisterMiyagi I'm not sure what you mean. Do you mean there should be more examples, or more commentary on the examples, or...?  
> **username_9** (2024-04-22): @IMSoP I might be missing something here but the answer seems to barely discuss  *syntax* and especially the *why* of it. For example, the **Functional programming languages** paragraph mostly explains currying, and how parentheses can be used *given* the Haskell syntax - but it does not say *why* the syntax was chosen that way. There's a bit that can be inferred here - that the syntax is *useful* with currying - but that isn't spelled out. Likewise, that `f (a b)` isn't "the mathematical f(a,b)" is shown but not pointed out; [...]  
> **username_9** (2024-04-22): [...] it's shown from the "if you want to do Y instead" angle, not the "it's not X" angle. IMO all the bits are there but not presented to address the question.  
> **username_7** (2024-04-22): @MisterMiyagi I've added a bunch more details - possibly too much, to be honest, but [I didn't have time to write a shorter letter](https://quoteinvestigator.com/2012/04/28/shorter-letter/). Does that cover what you felt was missing? (I always find "why" questions difficult - ultimately, the answer to "why does Haskell look that way?" is "because the people who designed it made it look that way").  
---
### Answer by username_8 on 2024-04-21. Score: 0
Programming languages use simple juxtaposition (`f a`) for function application because it is the standard notation for function application that has been used for more than 100 years, before the first electronic computers or high-level programming languages existed.

When there are mulitple arguments or other expressions involved, you would need parentheses to disambiguate. For example, one would use `f(a + b)` to apply `f` to the result of `a+b`, while `f a + b` would instead apply `f` to `a` and then add `b` to the result. So the real question is "why did languages start requiring parentheses for function application even when they are not needed for precedence/disambiguation?"

This originated with FORTRAN, which had two features that interact to require the parentheses:

* Multi-character names are allowed for things, so something like `fab` would be a single symbol, and not series of symbols involving some function applications
* Whitespace is completely insignificant and ignored, so `f a b` and `fab` are the same.

This was then carried over into later languages, even when they made whitespace significant.
> **Comments:**
> **username_7** (2024-04-21): The current top answer to [this related question](https://langdev.stackexchange.com/q/1372/1769) asserts exactly the opposite of your first paragraph: that `f(x)` is the most common mathematical notation. That certainly matches my (non-expert) experience: `f x` represents multiplication, not function application. Neither that answer nor this one backs the claim up very well, but Wikipedia attributes the parenthetical notation to Euler in 1734, citing [this textbook which is available on archive.org](https://archive.org/details/CALCULUS10THEDITIONRONLARSON/page/n41/mode/2up).  
> **username_10** (2024-04-21): There is some truth to your statement about juxtaposition, but note that `f a b` in maths is equivalent to `f(a(b))`, not `f(a, b)`. So if `a` and `b` are just real values, `a(b)` would be the product of `a` and `b`, and `f` is applied on that product.  
> **username_11** (2024-04-21): This answer is misleading. According to Cajori, "A History of Mathematical Notations", volume 2, paragraph 643, function notations both with and without parentheses are quite old: "The use of parentheses for [enclosing the variable of a function] occurs in Euler in 1734, who says, "Si $f(x/a + c)$ denotet functionem quamcunque ipsius $x/a + c$."... About the same time Clairaut designates a function of $x$ by $\Pi x$, $\Phi x$, or $\Delta x$, without using parentheses." Obviously, the notation with parentheses ended up becoming more popular in mathematics.  
> **username_8** (2024-04-25): @RobertR: your quote from Cajori supports my position -- the parens are used to disambiguate when there are mulitple arguments or an expression to be gathered,  and not when using a simple function of one argument.  
> **username_11** (2024-04-25): @ChrisDodd Your answer says that juxtaposition, with *optional* parentheses, has been the standard function application notation for over 100 years, which isn't true. Different fields of math/CS have different standards that have evolved over time, but today the standard in most fields of math/CS is undeniably juxtaposition with *mandatory* parentheses. ...  
> **username_11** (2024-04-25): ... The Euler example in passage I quoted is misleading, because the expression in the parentheses is composite, but mathematicians in the 1700's *did* write function applications to a single variable with parentheses, and some even wrote applications to multiple variables *without* parentheses. E.g., here's the very next two sentences from the passage I previously quoted: "In 1747 D'Alembert marked functions of two variables $u$ and $s$ by the signs $\Delta u,s$, $\Gamma u,s$. In 1754 he says: "Soit $\varphi(z)$ une fonction de la variable $z$, ..."."  
> **username_7** (2024-04-27): I wonder if there is a difference between different areas of mathematics, or different parts of the world, or some other reason why we're at odds here. I'm clearly not alone in thinking that a single-parameter function is written $f(x)$ rather than $fx$ or $f \ x$; but you seem very confident of the opposite. It would be really useful to have some context of where you have seen this.  
---
