How difficult would it be to add the infix notation à la Haskell?

The question is: why? You kind of get it with pipes (see the example you’ve shown).

That’s an entirely subjective judgement.

In my personal view Haskell got a bit sidetracked from “lambda calculus” by trying to mimic “mathematical notation”.

What’s so special about functions of arity 2 that they deserve some special place in the universe to be “promoted to operators”? Functions are simple, operators merely confuse the issue (then there is the ternary operator - but there can’t be an infix notation for that).

And I’m fully aware that my opinion is informed, coloured, biased from Clojure (i.e. Lisp) - what can be more simple than (fn a b c d)?

(+ a b) may not look very mathematical but it conforms in a world built on functions …

Not really, IMHO

pipes are great for pipelines

a 
|> b
|> c

infix notation is useful when it makes more sense, it is particularly evident when the function works as an operator

if 5 `rem` 3 == 0 do
  ...

compare it too

if rem(5, 3) == 0 do

if 5 |> rem(3) == 0 do

but also

state = Enum.into([a: 1, b: 2], %{})
# or
state = [a: 1, b: 2] |>  Enum.into(%{})

VS

state = [a: 1, b: 2] `Enum.into` %{}

there are a lot of cases when the infix notation is just more natural

it removes a lot of the clutter

Elixir separate operators from functions as well, operators are functions with arity 1 or 2

from: elixir/lib/elixir/lib/kernel.ex at v1.2 · elixir-lang/elixir · GitHub

@doc """
 Arithmetic addition.
 Allowed in guard tests. Inlined by the compiler.
 ## Examples
     iex> 1 + 2
     3
 """
 @spec (number + number) :: number
 def left + right do
   :erlang.+(left, right)
 end

(+ a b) may not look very mathematical but it conforms in a world built on functions …

It is harder for many people to understand

We are not RPN calculators or Yoda

Even if it more readable in some cases, we need very strong reasons to add yet another way of doing things to the language, and I am afraid we don’t have enough pros here to justify it, especially because “more natural” and “readability” mostly boils down to personal preference.

Such feature will complicate the grammar and understanding of the language. If we add it, now every team will ask themselves: when do we use the infix notation? Should we always use it? Never use it? And this is time better spent elsewhere.

and I am afraid we don’t have enough pros here to justify it

I understand the motivation behind the why not, I really do.

My question was how hard would it be, considering that Elixir can already extend operators, but only some of them.

It shouldn’t be the Haskell way (<backtick>function<backtick>) I was wondering if it there could be a way to support it through meta programming in the future.

Parentheses rule! And it is simple and extremely consistent as everything has the same format.

That is simply pandering to familiarity - in the hopes of gaining popularity.

It is harder for many people to understand

Have you actually pondered why that is? My hypothesis is that we are taught operators before functions - so we get used to operators before functions. But once you understand functions (something applied to a list of data) the notion of operators becomes superfluous (obsolete?). Yet we hang on to it even though it may be an idea who’s time has passed.

We are not RPN calculators

• That’s postfix
• It makes sense in the context of a stack based architecture
• Ultimately our brain is a pattern matcher
• When patterns change we have to adapt
• The root of the problem: we hate different, we hate change

state = [a: 1, b: 2] |> Enum.into(%{})

As per style guide that is a no-no. And even pipes aren’t a universal panacea anyway.

I completely agree with the consistency argument, maybe I should have explained where my question comes from first.

I also want to say that my question was genuinely how difficult would it be.
I wasn’t asking to vote for the addition to the language anytime soon.

I’m working right now in a large company where a lot of the new hires are data scientist, with mainly a physics or statistics background, not a computer science one (so… no Lisp, no S-expressions).

They use Python a lot, in a very bad way.
One of the problems of Python is exactly inconsistency, everything can be done in at least two ways and both of them are equally correct.
Of course everyone tend to mix the two ways as they please.

I’m writing Elixir and Erlang code for them, I sold them the BEAM with the fault tolerant and easy concurrency arguments, but now I need to teach other people to interact with the code, and I’m having some difficulties (more than I anticipated) getting the new guys to grasp all the concepts, not just the language(s).

They also know quite well R, which is a kinda complex language, they are smart, but too much is different from what they already know.

I’ve started looking for a way to write Python differently, just for the purpose of getting them used to the functional paradigm in Python, so I showed them Coconut lang.

They immediately thought this is better for pattern matching, not so much for the |> operator.

Coming from their background f(g(x)) (and also of course (f (g x))) makes sense, x |> g |> f not really, while they had no problem with the infix notation and that’s when it clicked, there are many occasions where the two are swappable (and many others where it would simply be wrong).

So i started wondering if there was a way to make the transition smoother.

That is simply pandering to familiarity - in the hopes of gaining popularity.

Which is good and it worked great.

You can still write
Kernel./(Kernel.+(some_num, other_num), some_other_hopefully_non_zero_num)
or
some_num |> Kernel.+(other_num) |> Kernel./(some_other_hopefully_non_zero_num)

if you want.
But it’s scary too look at.
And it also starts a wave of new questions:
why Kernel.+(10, 5) but not +(10, 5)?
And why the unary version works both ways Kernel.+(10) == +(10)?

The root of the problem: we hate different, we hate change

That’s exactly what I was trying to avoid: change everything at once.

As per style guide that is a no-no.

Believe me, if I asked the question is because, and I’m quoting you,

Ultimately our brain is a pattern matcher

once people start to see a pattern emerge, they’ll use that pattern everywhere, even when they shouldn’t.
And that’s how the bad ones are born.
I noticed that often a good looking pattern works better than forcing people to read a style guide or use a linter.

In the end, I’m sure eventually they’ll get there, even without the infix notation

Thanks for the discussion.

Ah, now we’re getting beyond the XY Problem.

You seem to be faced with transitioning people away from a monoglot mindset, towards a polyglot mindset.

once people start to see a pattern emerge, they’ll use that pattern everywhere, even when they shouldn’t.

It’s also easier to simply dump variables into a global namespace but as a community we have recognized that that is a bad idea. Similarly patterns have to be compartmentalized by context. R wasn’t designed to solve the same problems as Elixir (Erlang) have.

Pandering to familiarity is tantamount to “the Mountain coming to Mohammed” and while it may work in a popularity contest, it can go only so far before it becomes ineffective.

So I think you need to be looking for advice on how to “help them understand” that it can be helpful to shift one’s mindset in order to solve certain problems more effectively. For example supervisors are completely foreign to people only used to exceptions.

I’m fond of Syntax is utterly irrelevant but Semantics is King. Syntax is irrelevant, but no it isn’t is actually closer to the truth. Actually watch @rvirding’s entire talk. It reinforces the notion of Beyond Functional Programming with Elixir and Erlang that Erlang (and by extension Elixir) is functional for pragmatic reasons, not to be cool.

Coming from their background f(g(x)) (and also of course (f (g x)) makes sense, x |> g |> f not really,

Lots of people rationalize pipelines as an FP replacement for method chaining/fluent interface from OO, personally I view it as using forward function application as a poor man’s replacement for actual function composition.

So I think the real challenge here is to convince your audience that the functional mindset has something to offer them. That may require you to more deeply get involved in what they are working on and how they do things, so that you can more effectively propose that doing some things “functionally” may make it simpler to solve particular problems.

Now that you have opened the dialog, hopefully there will be lots of suggestions of how to make that happen.