Why do we use a dot to call a function?

You do use the dot for functions bound to variables. Not for defined functions,

iex(1)> defmodule M do
...(1)>   def foo(a), do: a + 1
...(1)> end
# ...
iex(2) foo = fn a -> a + 1 end
# ...
iex(3) M.foo(1)
2
iex(4) foo.(1)
2

This is mainly to distinguish in case of nameclashes.

I don’t get the point Sorry.

When could we have any problem calling foo(1) in place of foo.(1) ?
From your code, is it for the case we have a function bound to foo variable inside the module M ?

Thanks

Just to clarify, these are refered to as anonymous functions. Which, as mentioned, are nameless and should be called using a dot and may also be defined using the & shorthand. Refer to this lesson for a better overview.

This is very contrived but shows my point:

defmodule M do
  def foo(a) do
    foo = fn b -> a + b end
    # foo(1) # Nope, this will result in an infinite loop; also compiler might complain about unused variable `foo`
    foo.(1) # this works!
  end
end

The dot is only used when calling anonymous functions that have been bound to a variable (and not functions defined inside a module). The dot also reminds us that it is an anonymous function.

This is an anonymous function:

foo = fn a -> a + 1 end

And called like this:

foo.(10)

This is a function defined inside a module:

defmodule MyModule do
  def foo(a), do: a + 1
end

And called like this:

MyModule.foo(10)

If you continue reading the book Dave goes on to explain this

This is also a great point - the name of the variable isn’t the name of the function:

foo = fn a -> a + 1 end

Here, foo is just the name of the variable that the anonymous function has been bound to - the function itself is nameless/anonymous.

Named functions always go inside a module:

defmodule MyModule do
  def foo(a), do: a + 1
end

Here, the name of the function is foo.

Specifically, we call this foo/1 where 1 is the arity (the number of arguments the function takes)

Joe Armstrong called it

I quote:

“If you leave it like this expect to spend the next twenty years of your
life explaining why. Expect thousands of mails in hundreds of forums.”

Haha, I have to admit that it was one of the things that I wondered myself - but I think that is also true of other things that are different to what we’re used to (or for some reason or another, feel peculiar to us). Once we learn about them it just makes sense and we move on.

With that said, I have been thinking about whether we could do with a Frequently Asked Questions section, as well as perhaps a Glossary section - for common stuff like this. We can then easily direct people to the associated thread whenever the topic comes up (with the added benefit them many people will browse such sections as well)

It has already been explained in this thread but for additional context this early thread may help as well. I do not think anyone mentions it directly but it is also important to know two things:

1. Elixir code compiles to Erlang AST
2. Erlang solves this ambiguity problem by requiring capital letters for variable names and lowercase for atoms (including module and function names). So there is no chance of ambiguity here.

Elixir solves the ambiguity between variable and atom names by prefixing atoms with a colon but including a colon in local function invocation seems like a worse trade-off than a dot for anonymous functions.

I think it is a shame though and easily the biggest remaining wart in the language, and the cost of it is probably a diminished usage of anonymous functions in everyday code.

I do use them as I need them and I like the erlang and elixir way.

In go code I write for work when I have a long function body in legacy code I often see foo() and then searching begins… My first reaction is scanning the list of functions on the right, but it’s not there. Then I scroll up to the current functions head to see if it is passed in as an argument, I don’t even find it there so I scroll even more up and see a dot imported package… I hate this ambiguity…

In elixir and erlang I can see at least if it is a variable or a “real” function.