Why tag function definition with def, fn, fun, func or function etc?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 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: the following code cannot define a function, because it is instead a statement (a function call) which has a type annotation (which is allowed to be an arbitrary expression):

foo(): bar()

If this had been allowed as a function definition in Python originally, then it would have created this problem when the designers later wanted to add type annotation syntax to the language.

Answer 5

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 6

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.