<p>What makes it hard for compilers/interpreters that we need to tag the function definition with keyword fn/fun/func/function?</p>
<p>I can understand that types for numbers: int, int32, float32, float64... are required. Otherwise, how will one figure out difference between 1 and 1.0 and &quot;1&quot; and so on.</p>
<p>But functions are only defined as <code>function name(param-list) { body }</code> and called as <code>name(args);</code> With programming languages differing on what to put in the signature/declaration line (what is that called?)</p>
<pre><code>fn sayHi() { }
fun sayHi() { }
func sayHi() { }
function sayHi() { }
</code></pre>
<p>Why cannot we have:</p>
<pre><code>sayHi() {}
</code></pre>
<p>What makes this complicated or impossible?</p>

<syntax><functions><declarations>
Why tag function definition with def, fn, fun, func or function etc?
CC BY-SA 4.0
2023-09-29T11:51:19.373Z
In `sh`, you *can't* have a `function` keyword and have to define functions like you describe with just the name.  `bash` and `zsh` added the ability to also use `function` keyword to make the code clearer to read.
Chris Dodd
CC BY-SA 4.0
2023-09-29T12:58:27.377Z
Is it worth pointing out that in some languages like `C` you can just say `void MyFunction() {}` and it recognises it as a function. So I don't think it's `hard` for a compiler/interpreter to parse a function, it just might not be as readable on some languages.
Tom Tsagkatos
CC BY-SA 4.0
2023-09-29T13:30:33.877Z
@Seggan I don't think it does; OP isn't asking about using the return type as a prefix, they're asking about having no prefix at all, which is much different.
rydwolf
CC BY-SA 4.0
2023-09-29T13:41:17.630Z
@TomTsagk: Just because one language did it doesn't mean it's not a terrible idea. In fact, the syntax of C -- and notably of function declarations -- is fairly problematic in general, requiring the maintenance of a symbol table when parsing, and leading to the [Most Vexing Parse](https://en.wikipedia.org/wiki/Most_vexing_parse) issue.
Matthieu M.
CC BY-SA 4.0
2023-09-29T14:05:17.950Z
@RydwolfPrograms the answers there can be mostly applied here too
Seggan
CC BY-SA 4.0
2023-09-29T15:33:34.067Z
Haskell defines functions without using a keyword: `square x = x * x` defines function `square`.
Christian Lindig
CC BY-SA 4.0
2023-09-30T11:01:02.817Z
This is not a duplicate of the question about type-first syntax; it's not about type annotations, and the benefit or need for a function-definition keyword like `function` is orthogonal to the question of whether the type annotation (assuming there is one) should go before or after the name it's associated with.
kaya3
CC BY-SA 4.0
2023-10-01T21:59:43.357Z
`sayHi() {}` is perfectly valid Dart (and not frowned upon, as opposed to the same code in C).
Luatic
<p>Generally speaking, error reporting is much better if you have function definition keywords. The reason is that the compiler can use them as anchor and do better guesswork what a malformed input likely should have meant.</p>
<p>In some languages, it is simply not possible in general to disambiguate field and function definitions without the keyword, because they can have forms that are, otherwise, completely identical. Tyr is such a language. It offers, inspired by Scala, a function definition syntax that uses a <code>=</code> followed by a single expression. Thus, the syntax for fields and functions without parameters is exactly the same except for the leading keyword. If one would drop such syntax, the parser would simply need to perform a lookahead and use the <code>{</code> equivalent as keyword for functions. It does not really make a difference.</p>

CC BY-SA 4.0
2023-09-29T18:38:05.487Z
2023-09-29T18:38:05.487Z
feldentm
CC BY-SA 4.0
2023-09-29T20:06:43.113Z
JS doesn't need `function` in class methods or object fields.
Anubhav
CC BY-SA 4.0
2023-10-03T17:31:37.527Z
@Anubhav: What syntax would allow writing a function in JS without using either either the keyword `function` or the token sequence `=>` which is a shorthand that is used exclusively for writing functions?
supercat
CC BY-SA 4.0
2023-10-05T11:45:03.883Z
`const obj = { add(a, b) { return a + b; } };` `class Human { constructor() {} squeak() { return "meh!"; } }`

both of these don't require `function` keyword.
Anubhav
CC BY-SA 4.0
2023-10-05T19:32:21.510Z
How long have those constructs been in JS?  Having an object initializer use braces as the outer delimiter but use a member name that isn't followed by a colon seems like a gratuitous syntactic variation with which to burden implementations.
supercat
<p>Generally, languages which require this do so for one of two reasons:</p>
<ul>
<li>The grammar would be ambiguous if function definitions didn't include a keyword like this,</li>
<li>Otherwise, if the grammar wouldn't actually be ambiguous, it would constrain future additions to the language syntax, and be harder for people to read.</li>
</ul>
<p>Consider Javascript: the following code cannot define a function, because it is instead a sequence of statements (a function call, then a block):</p>
<pre class="lang-js prettyprint-override"><code>foo()
{
    bar();
}
</code></pre>
<p>Consider Python: if the following code could define a function, then it would be impossible to later extend the <a href="https://typing.readthedocs.io/en/latest/spec/annotations.html" rel="nofollow noreferrer">type annotation syntax</a> to allow annotating statements, because this would be a statement (a function call) with a type annotation:</p>
<pre class="lang-python prettyprint-override"><code>foo(): ...
</code></pre>

CC BY-SA 4.0
2023-09-29T20:57:22.733Z
2024-11-01T14:47:13.767Z
2024-11-01T14:47:13.767Z
kaya3
CC BY-SA 4.0
2023-09-29T21:31:01.503Z
What are you talking about? `foo() { ... }` is a definition. `bar();` is an execution because a) `;` and b) no following `{}`
Anubhav
CC BY-SA 4.0
2023-09-29T21:51:18.950Z
@Anubhav: In javascript, the semicolons at the end of the line are optional.
Chris Dodd
CC BY-SA 4.0
2023-09-29T22:00:48.937Z
@Anubhav [Try it online](https://tio.run/##y0osSyxOLsosKNEts/ifVpqXXJKZn6eQlp@voalQrZCcn1ecn5Oql5OfrqGenJiTk5oCklPXtFao5YKrTkoswqkaKAdW/R9sJFc1lwIQgDVYc9X@/w8A).
kaya3
<p><a href="https://en.wikipedia.org/wiki/Chris_Lattner" rel="nofollow noreferrer">Chris Lattner</a> explains the rationale for <code>func</code> in Swift <a href="https://forums.swift.org/t/question-out-of-curiosity-why-func/2058/5" rel="nofollow noreferrer">in this post</a></p>
<blockquote>
<p>Swift’s grammar follows a very regular structure, where declarations are introduced with a keyword. This structure has a number of advantages when parsing. For example, it allows “modifiers” like “mutating” and “public” to be context sensitive identifiers instead of themselves being keywords. It also helps with more subtle things like error recovery in the face of invalid code that produces parsing errors.</p>
<p>-Chris</p>
</blockquote>

CC BY-SA 4.0
2024-10-29T01:28:32.423Z
2024-10-29T01:28:32.423Z
Alexander
<p>First off, general purpose languages are always a multitude of trade offs. In some esoteric language, you might not have have functions, let named functions.</p>
<p>Function identifiers are a trade off between brevity and easy identification (for both humans and parsers). I would suggest that ease of identification by humans is, for most languages, not of extreme importance, but at the very least highly important.</p>

CC BY-SA 4.0
2023-10-01T23:21:16.190Z
2023-10-01T23:21:16.190Z
jmoreno
<p>As others point out, we don't need to.
All you need is
<span class="math-container">$\lambda x.M$</span>. Syntax like</p>
<p><span class="math-container">$$\mathsf{let}\ x\ =\ M\ \mathsf{in}\  N$$</span> is just convenient syntax for    <span class="math-container">$(\lambda x.N)M$</span>,
and, likewise,
<span class="math-container">$$\mathsf{fun}\ f(x_1, ..., x_n)\ =\ M\ \mathsf{in}\ ...$$</span>
is just convenient syntax for <span class="math-container">$\mathsf{let}\ f\ =\ \lambda x_1. ... \lambda x_n.M\ \mathsf{in}\  ...$</span>
So it's all just about readability and convention.</p>

CC BY-SA 4.0
2023-09-30T11:43:42.287Z
2023-09-30T11:43:42.287Z
Martin Berger
CC BY-SA 4.0
2023-09-30T12:43:24.570Z
The $\lambda$ symbol serves the same purpose as a keyword like `function`. So this doesn't answer the question: why do you need the lambda? Or the `let`, for that matter?
kaya3
CC BY-SA 4.0
2023-09-30T13:23:45.790Z
@kaya3 You need some syntax to distinguish every syntactic form, that's inevitable. Rather than $\lambda x.M$ one might also just use $x.M$ and then the dot disambiguates. The point I was trying to make is that introduction of functions can be simpler, for example functions can be anonymous.
Martin Berger
CC BY-SA 4.0
2023-09-30T14:44:42.843Z
What makes $\lambda$ inherently simpler than `function`?
kaya3
CC BY-SA 4.0
2023-09-30T15:07:27.520Z
@kaya3 Lambda does not need to *name* the function.
Martin Berger
CC BY-SA 4.0
2023-09-30T17:37:24.790Z
Neither does `function`, e.g. in Javascript `function() { ... }`.
kaya3
<p>Your code</p>
<pre><code>sayHi() {}
</code></pre>
<p>does work in C. That's a function that returns an integer. It also works in sh if the body is not empty. More complicated languages usually don't support this, probably only because of ambiguity. It's too similar to something like:</p>
<pre><code>while(1) {}
</code></pre>
<p>Actually, many languages, even if once required a <code>function</code> keyword, now supports something like this:</p>
<pre><code>sayHi = () =&gt; {}
</code></pre>
<p>But someone could argue that two operators may not be simpler than one keyword. It is supported because we have more possible &quot;differences&quot; now, that is the option to not assign a function to a name.</p>
<p>As more features are made into programming languages, there could be more variations of functions, say generators, virtual, inline, ... I don't think anyone would want to go back and think of removing every tag. They only simplify a tag to an operator because it is used too frequently. But if someone really wants so, I'd argue something that is consist of a name, a list and a body isn't intuitively only possibly a function. Languages with the simplified syntax may have excluded the other possibilities in the design. Many languages have high order functions, but some simple languages may choose to never support them. And using <code>=</code> in place of something like <code>=&gt;</code> may mix the definition with array element assignment, but that's not a problem in functional programming languages. And I think ambiguity is the only valid reason.</p>

CC BY-SA 4.0
2023-09-29T19:53:41.517Z
2023-09-29T19:53:41.517Z
user23013
CC BY-SA 4.0
2023-09-29T20:05:06.630Z
`while` is a keyword. `1` is an arg not a param.
Anubhav
<p>The short answer here is that we <em>don't</em> need to tag functions in the way you described. The C family of languages, for example, typically does something like</p>
<pre><code>type functionName(args...) {...}
</code></pre>
<p>where there is no <code>fn</code>, <code>function</code>, <code>func</code>, or anything similar.</p>
<p>Some languages, like Haskell and OCaml, allow for an even more terse syntax.
In both languages, you can create a function with something like</p>
<pre><code>let myFn arg1 arg2 ... argN = ...
</code></pre>
<p>and you could call it later just by writing</p>
<pre><code>myFn 10 11 12 ... 50
</code></pre>
<p>(imagine our function accepts natural numbers).</p>
<p>Depending on the language and the grammar, the function keyword might be there to avoid ambiguities and simplify parsing. Given enough engineering effort, though, I would assume it to be possible for many languages to get rid of their respective function keywords. So, in my opinion, the answer boils down to this: those keywords are there to help <em>you</em>, not the compiler.</p>
<p>Here is another example, in the untyped lambda calculus. I am going to leave
out the <span class="math-container">$\lambda$</span> symbol (which is equivalent to <code>fn</code> or <code>func</code> in other languages, but not necessary for parsing). You try to tell me what is going on.</p>
<pre><code>n.f.x.n(g.h.h(g f))(u.x)(u.u)
</code></pre>
<p>Admittedly, this would be difficult to unpack in normal lambda calculus, but in this form, it is even harder. (It is the predecessor function for Church encoded numerals, if you're curious).</p>
<p>Anyway. It is there to help you, not the compiler.</p>

CC BY-SA 4.0
2023-09-29T13:41:56.057Z
2023-09-29T13:41:56.057Z
Luke LaBonte
CC BY-SA 4.0
2023-09-29T20:13:49.663Z
`λ` is the name of the function. The name is anonymous. Thus `λx.t` takes in x as a param and returns t. Similar case in javascript would be `x2t(x) { return t; }` or `x2t = x => t`. 

I am talking about using a tag for describing "what follows is a function" which haskell, ocaml already don't have. If those languages had such a tag it would be something like `f(λx.t)` and then you would be omitting `f` because that denotes a function.
Anubhav
CC BY-SA 4.0
2023-09-29T20:56:50.763Z
@Anubhav I'm not sure what you mean. If $\lambda$ was the name of the function, then it could not be anonymous by definition. The $\lambda$ is just syntax, and quite literally means that what follows is an anonymous function. Also, both Haskell and OCaml *do* have symbols for just this purpose; OCaml uses `fun`, and Haskell uses ``\`` (because it looks similar to a $\lambda$ if you squint a little). Its just that you don't actually need to use those to define functions.
Luke LaBonte
CC BY-SA 4.0
2023-09-29T21:36:50.393Z
Take `toString` for example. Takes a number, returns the string representation of the number, somthing like `toString :: num -> string` 

Suppose `f` is used to mark a piece of code in haskell as a function. Then the example above will become, `f toString :: num -> string`. I am talking about can haskell do without `f` (which I think it alread does). This but in languages like JS, Go, Kotlin, Rust....
Anubhav
CC BY-SA 4.0
2023-09-29T21:57:46.507Z
@Anubhav JS, Go, Kotlin, Rust, and others could remove the `f`. It would not make it too difficult for the compilers. It may introduce some difficult parsing edge cases, but that is a problem we already deal with. I believe the reason language designers keep the `f` is to make the language more readable for you, the programmer.
Luke LaBonte
CC BY-SA 4.0
2024-10-29T23:08:03.340Z
I don't see how your presentation of the predecessor function is *harder* to read than its lambda-prefixed version. Can you elaborate?
user76284
# Why tag function definition with def, fn, fun, func or function etc?
Posted by: username_0 on 2023-09-29
What makes it hard for compilers/interpreters that we need to tag the function definition with keyword fn/fun/func/function?
I can understand that types for numbers: int, int32, float32, float64... are required. Otherwise, how will one figure out difference between 1 and 1.0 and "1" and so on.
But functions are only defined as function name(param-list) { body } and called as name(args); With programming languages differing on what to put in the signature/declaration line (what is that called?)
fn sayHi() { }
fun sayHi() { }
func sayHi() { }
function sayHi() { }

Why cannot we have:
sayHi() {}

What makes this complicated or impossible?
**Tags:** syntax functions declarations
> **Comments:**
> **username_1**: In `sh`, you *can't* have a `function` keyword and have to define functions like you describe with just the name.  `bash` and `zsh` added the ability to also use `function` keyword to make the code clearer to read.  
> **username_2**: Is it worth pointing out that in some languages like `C` you can just say `void MyFunction() {}` and it recognises it as a function. So I don't think it's `hard` for a compiler/interpreter to parse a function, it just might not be as readable on some languages.  
> **username_3**: @Seggan I don't think it does; OP isn't asking about using the return type as a prefix, they're asking about having no prefix at all, which is much different.  
> **username_4**: @TomTsagk: Just because one language did it doesn't mean it's not a terrible idea. In fact, the syntax of C -- and notably of function declarations -- is fairly problematic in general, requiring the maintenance of a symbol table when parsing, and leading to the [Most Vexing Parse](https://en.wikipedia.org/wiki/Most_vexing_parse) issue.  
> **username_5**: @RydwolfPrograms the answers there can be mostly applied here too  
> **username_6**: Haskell defines functions without using a keyword: `square x = x * x` defines function `square`.  
> **username_7**: This is not a duplicate of the question about type-first syntax; it's not about type annotations, and the benefit or need for a function-definition keyword like `function` is orthogonal to the question of whether the type annotation (assuming there is one) should go before or after the name it's associated with.  
> **username_8**: `sayHi() {}` is perfectly valid Dart (and not frowned upon, as opposed to the same code in C).  
---
## 7 answers
### Answer by username_15 on 2023-09-29. Score: 14
The short answer here is that we don't need to tag functions in the way you described. The C family of languages, for example, typically does something like
type functionName(args...) {...}

where there is no fn, function, func, or anything similar.
Some languages, like Haskell and OCaml, allow for an even more terse syntax.
In both languages, you can create a function with something like
let myFn arg1 arg2 ... argN = ...

and you could call it later just by writing
myFn 10 11 12 ... 50

(imagine our function accepts natural numbers).
Depending on the language and the grammar, the function keyword might be there to avoid ambiguities and simplify parsing. Given enough engineering effort, though, I would assume it to be possible for many languages to get rid of their respective function keywords. So, in my opinion, the answer boils down to this: those keywords are there to help you, not the compiler.
Here is another example, in the untyped lambda calculus. I am going to leave
out the $\lambda$ symbol (which is equivalent to fn or func in other languages, but not necessary for parsing). You try to tell me what is going on.
n.f.x.n(g.h.h(g f))(u.x)(u.u)

Admittedly, this would be difficult to unpack in normal lambda calculus, but in this form, it is even harder. (It is the predecessor function for Church encoded numerals, if you're curious).
Anyway. It is there to help you, not the compiler.
> **Comments:**
> **username_0** (2023-09-29): `λ` is the name of the function. The name is anonymous. Thus `λx.t` takes in x as a param and returns t. Similar case in javascript would be `x2t(x) { return t; }` or `x2t = x => t`. 

I am talking about using a tag for describing "what follows is a function" which haskell, ocaml already don't have. If those languages had such a tag it would be something like `f(λx.t)` and then you would be omitting `f` because that denotes a function.  
> **username_15** (2023-09-29): @Anubhav I'm not sure what you mean. If $\lambda$ was the name of the function, then it could not be anonymous by definition. The $\lambda$ is just syntax, and quite literally means that what follows is an anonymous function. Also, both Haskell and OCaml *do* have symbols for just this purpose; OCaml uses `fun`, and Haskell uses ``\`` (because it looks similar to a $\lambda$ if you squint a little). Its just that you don't actually need to use those to define functions.  
> **username_0** (2023-09-29): Take `toString` for example. Takes a number, returns the string representation of the number, somthing like `toString :: num -> string` 

Suppose `f` is used to mark a piece of code in haskell as a function. Then the example above will become, `f toString :: num -> string`. I am talking about can haskell do without `f` (which I think it alread does). This but in languages like JS, Go, Kotlin, Rust....  
> **username_15** (2023-09-29): @Anubhav JS, Go, Kotlin, Rust, and others could remove the `f`. It would not make it too difficult for the compilers. It may introduce some difficult parsing edge cases, but that is a problem we already deal with. I believe the reason language designers keep the `f` is to make the language more readable for you, the programmer.  
> **username_16** (2024-10-29): I don't see how your presentation of the predecessor function is *harder* to read than its lambda-prefixed version. Can you elaborate?  
---
### Answer by username_9 on 2023-09-29. Score: 5
Generally speaking, error reporting is much better if you have function definition keywords. The reason is that the compiler can use them as anchor and do better guesswork what a malformed input likely should have meant.

In some languages, it is simply not possible in general to disambiguate field and function definitions without the keyword, because they can have forms that are, otherwise, completely identical. Tyr is such a language. It offers, inspired by Scala, a function definition syntax that uses a `=` followed by a single expression. Thus, the syntax for fields and functions without parameters is exactly the same except for the leading keyword. If one would drop such syntax, the parser would simply need to perform a lookahead and use the `{` equivalent as keyword for functions. It does not really make a difference.
> **Comments:**
> **username_0** (2023-09-29): JS doesn't need `function` in class methods or object fields.  
> **username_10** (2023-10-03): @Anubhav: What syntax would allow writing a function in JS without using either either the keyword `function` or the token sequence `=>` which is a shorthand that is used exclusively for writing functions?  
> **username_0** (2023-10-05): `const obj = { add(a, b) { return a + b; } };` `class Human { constructor() {} squeak() { return "meh!"; } }`

both of these don't require `function` keyword.  
> **username_10** (2023-10-05): How long have those constructs been in JS?  Having an object initializer use braces as the outer delimiter but use a member name that isn't followed by a colon seems like a gratuitous syntactic variation with which to burden implementations.  
---
### Answer by username_7 on 2023-09-29. Score: 4
Generally, languages which require this do so for one of two reasons:

The grammar would be ambiguous if function definitions didn't include a keyword like this,
Otherwise, if the grammar wouldn't actually be ambiguous, it would constrain future additions to the language syntax, and be harder for people to read.

Consider Javascript: the following code cannot define a function, because it is instead a sequence of statements (a function call, then a block):
foo()
{
    bar();
}

Consider Python: if the following code could define a function, then it would be impossible to later extend the type annotation syntax to allow annotating statements, because this would be a statement (a function call) with a type annotation:
foo(): ...
> **Comments:**
> **username_0** (2023-09-29): What are you talking about? `foo() { ... }` is a definition. `bar();` is an execution because a) `;` and b) no following `{}`  
> **username_1** (2023-09-29): @Anubhav: In javascript, the semicolons at the end of the line are optional.  
> **username_7** (2023-09-29): @Anubhav [Try it online](https://tio.run/##y0osSyxOLsosKNEts/ifVpqXXJKZn6eQlp@voalQrZCcn1ecn5Oql5OfrqGenJiTk5oCklPXtFao5YKrTkoswqkaKAdW/R9sJFc1lwIQgDVYc9X@/w8A).  
---
### Answer by username_14 on 2023-09-29. Score: 3
Your code
sayHi() {}

does work in C. That's a function that returns an integer. It also works in sh if the body is not empty. More complicated languages usually don't support this, probably only because of ambiguity. It's too similar to something like:
while(1) {}

Actually, many languages, even if once required a function keyword, now supports something like this:
sayHi = () => {}

But someone could argue that two operators may not be simpler than one keyword. It is supported because we have more possible "differences" now, that is the option to not assign a function to a name.
As more features are made into programming languages, there could be more variations of functions, say generators, virtual, inline, ... I don't think anyone would want to go back and think of removing every tag. They only simplify a tag to an operator because it is used too frequently. But if someone really wants so, I'd argue something that is consist of a name, a list and a body isn't intuitively only possibly a function. Languages with the simplified syntax may have excluded the other possibilities in the design. Many languages have high order functions, but some simple languages may choose to never support them. And using = in place of something like => may mix the definition with array element assignment, but that's not a problem in functional programming languages. And I think ambiguity is the only valid reason.
> **Comments:**
> **username_0** (2023-09-29): `while` is a keyword. `1` is an arg not a param.  
---
### Answer by username_11 on 2024-10-29. Score: 2
[Chris Lattner](https://en.wikipedia.org/wiki/Chris_Lattner) explains the rationale for `func` in Swift [in this post](https://forums.swift.org/t/question-out-of-curiosity-why-func/2058/5)

> Swift’s grammar follows a very regular structure, where declarations are introduced with a keyword. This structure has a number of advantages when parsing. For example, it allows “modifiers” like “mutating” and “public” to be context sensitive identifiers instead of themselves being keywords. It also helps with more subtle things like error recovery in the face of invalid code that produces parsing errors.
>
> -Chris
---
### Answer by username_12 on 2023-10-01. Score: 0
First off, general purpose languages are always a multitude of trade offs. In some esoteric language, you might not have have functions, let named functions.

Function identifiers are a trade off between brevity and easy identification (for both humans and parsers). I would suggest that ease of identification by humans is, for most languages, not of extreme importance, but at the very least highly important.
---
### Answer by username_13 on 2023-09-30. Score: -2
As others point out, we don't need to.
All you need is
$\lambda x.M$. Syntax like

$$\mathsf{let}\ x\ =\ M\ \mathsf{in}\ N$$ is just convenient syntax for $(\lambda x.N)M$,
and, likewise,
$$\mathsf{fun}\ f(x\_1, ..., x\_n)\ =\ M\ \mathsf{in}\ ...$$
is just convenient syntax for $\mathsf{let}\ f\ =\ \lambda x\_1. ... \lambda x\_n.M\ \mathsf{in}\ ...$
So it's all just about readability and convention.
> **Comments:**
> **username_7** (2023-09-30): The $\lambda$ symbol serves the same purpose as a keyword like `function`. So this doesn't answer the question: why do you need the lambda? Or the `let`, for that matter?  
> **username_13** (2023-09-30): @kaya3 You need some syntax to distinguish every syntactic form, that's inevitable. Rather than $\lambda x.M$ one might also just use $x.M$ and then the dot disambiguates. The point I was trying to make is that introduction of functions can be simpler, for example functions can be anonymous.  
> **username_7** (2023-09-30): What makes $\lambda$ inherently simpler than `function`?  
> **username_13** (2023-09-30): @kaya3 Lambda does not need to *name* the function.  
> **username_7** (2023-09-30): Neither does `function`, e.g. in Javascript `function() { ... }`.  
---
