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

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 92995 915
New
caslu
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
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
Herve37
We’re evaluating API mocking tools for OpenAPI-based projects and would love to hear what other teams are using. We’re particularly inte...
New
GES233
I’m posting this in response to Jose’s recent tweet (Cr. link) : People are sleeping on Elixir for a coding harness: Hot-code swappi...
New
_mfierro
Hello, I wrote Stop My Hand, a Scattergories-like web application using Phoenix/LiveView as my learning project for Elixir (after readin...
New
nseaSeb
AcmeScript — Writing JS hooks as if I were still using Elixir I’ve been having fun building a little something over the last few days: Ac...
New

Other Trending Topics Top

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
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
wintermeyer
There are three potential reasons for members of this forum to have a look at https://vutuv.de You are tired or annoyed of LinkedIn. Yo...
New
webofbits
Aludel - LLM Evaluation Workbench Aludel is an embeddable Phoenix LiveView dashboard for evaluating and comparing LLM prompts across mult...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews