Elixir definition of functions without parenthesis

Chat / Discussions
1

Since Elixir’s type system is becoming a new topic, can I take the chance to request a feature to be introduced around functions?

Namely, to be able to define functions without parenthesis around its arguments.

def sayhi "world", do: "Hello" <> " world!"
def sayhi("world"), do: "Hello" <> " world!"

Why?

For simplicity. Elixir is mainly a declarative programming language, not imperative. It is a very flexible language and those parenthesis can be left to erlang’s rigid syntax. And anyway let anyone adopt the convention he best finds. I find functions without parenthesis clearer.

Why not?

let me know! :slight_smile:

1 Like
2

You should try Lisp. :grin:

4 Likes
3

Your example would be ambiguous, is , do: ... an argument to def or to sayhi?
Essentially it can be interpreted in two ways:

def(sayhi("world", do: "Hello" <> " world!"))
def(sayhi("world"), do: "Hello" <> " world!")

It’s the same reason the lack of parenthesis make pipeline expressions ambiguous, for example:

foo bar, baz |> IO.inspect

Can be

foo(bar, baz) |> IO.inspect()
foo(bar, baz |> IO.inspect())

And there’s no way for the compiler/parser to tell which one do you mean

7 Likes
4

This is specifically a limitation of the single-line , version of def, the multiline version is fine without parens:

def sayhi "world" do
  "Hello" <> " world!"
end

The tricky part of supporting that syntax in single line is context-sensitivity - the comma’s meaning in this definition changes depending on the tokens that follow it.

def sayhi_with_kwarg "world", do: "Hello" <> " world!"
# versus
def sayhi_with_kwarg "world", do: "Hello" <> " world!" do
  :ok
end

Before the second do is seen, the , separates the arguments from the definition. After, it delimits the first argument from the second.

2 Likes
5

Let me guys propose a solution.

The elixir interpreter fails to evaluate the following expression (good news):

def(sayhi("world", do: "Hello" <> " world!"))

it does not have a block do expression, so it is what we would expect: an error for a function without do.

But (if arguments without parenthesis implemented) so would the following expression be an error, because it does not have a do block.

def sayhi_with_kwarg "world", do: "Hello" <> " world!"

It contains two values world and the keyword argument. Yet! The interpreter could understand that what is trying to be expressed is a do block and not a value, because otherwise it would make little sense, if any, define a function without a do block.

And since a function definition must expect an atom for do let the interpreter identify such keyword list that contains only this expected keyword list definition for the function.

With this in mind,

def sayhi_with_kwarg "world", do: "Hello" <> " world!"

would turn into

def(sayhi("world"), do: "Hello" <> " world!")

Fine. And since we expect this from the interpreter, the following would be totally fine as well:

def sayhi_with_kwarg "world", do: "Hello" <> " world!", do: "Hello" <> " world!"

leaving the last keyword-list expression as the do block of the function.

Effectively resulting in (as an example):

def sayhi_with_kwarg "world", do: "Hello" <> " world!" do
  "Hello" <> " world!"
end

Am I missing something? :slight_smile:

6

def and similar are macros, they abide by the same rules as any other macro, so the compiler doesn’t “know” it’s a function definition until the macros are fully expanded.
There are also cases where the function definition has no body:

def foo(bar, opts \\ [])

def foo(:a, opts) do ... end
def foo(:b, opts) do ... end
3 Likes
7

Then I have no option but to stick with Lisp.

Kidding :smiley:. I see. I can only guess, if no the compiler, let the macro expand all arguments, and place the last keywordlist do as its function body, but I’m probably fully mistaken until I understand how macros in elixir work.

Perhaps there is an initiative for this feature by the masterminds of elixir one day. Thank you for all your answers!

8

Can you explain this more? I’m not a language nerd**, but am curious/interested in this type of thing.

Heh… I hate parens when there are no args, but am a fan of parens when there are. Seems very DSL-y to not have parens, but I kinda like Elixir’s “don’t use DSLs if they can be avoided” type mentality.

** No offense intended by that term. I’ve met a lot of people who self describe as “language nerds” when trying to explain they are really into programming language design.

1 Like
9

Welcome to the forum!

Regarding this feature, I personally would rather this not be available. Elixir already has many cases where parentheses are optional, and I feel this needlessly adds “optionality” into the language such that everyone does it different. In fact, I use Credo to enforce that parentheses are included when defining functions with no arguments. The reason is that otherwise, they end up looking like properties or variables or something, when they are still functions and must be called with parentheses when used anyway.

In fact, a lot of official documentation and books have code without parentheses that have them put back by the official Elixir formatter, usually revolving around the use of macros. I feel that’s a showcase where allowing no parentheses in the first place is not really even worth it.

Lastly, there are some weird issues with leaving off parentheses and pipelines. I don’t think Elixir is really built with a no-parentheses style in mind.

iex(3)> 2 |> Kernel.+ 34
warning: parentheses are required when piping into a function call. For example:

    foo 1 |> bar 2 |> baz 3

is ambiguous and should be written as

    foo(1) |> bar(2) |> baz(3)

Ambiguous pipe found at:
  iex:3:3

36
2 Likes