vladic4t

vladic4t

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:

Showing Posts 1 to 8

Sebb

Sebb

You should try Lisp. :grin:

dorgan

dorgan

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

al2o3cr

al2o3cr

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.

vladic4t

vladic4t OP

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:

dorgan

dorgan

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
vladic4t

vladic4t OP

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!

cjbottaro

cjbottaro

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.

bmitc

bmitc

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
— All posts loaded —

Where Next? Top

Trending in Discussions Top

cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
achempion
I’ve been using Emacs as my main code editor for more than a two years. It’s a custom build version although I’ve tried doom emacs and sp...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews