If they know R, they may know the tidyverse set of libraries and it’s pipe operator %>% so there may be a way “in” there for at least some of this.
chrismcg
0
massimo
Ah, now we’re getting beyond the XY Problem .
Sorry, but no.
Don’t mean to be rude, but as I’ve said few times already, I’ve only asked how difficult would it be.
I really wanted to know how hard would it be.
That’s all.
Thanks.
1
massimo
Thanks to the great Elixir’s meta programming capabilities I was able to hack together the code below.
It’s just a quick experiment I did for my own amusement, nobody in his right mind should use it 
I believe that giving programmers the freedom to extend the language can work in the same way custom keybindings and plugins in modern editors make them “right for your fingers”.
Kudos to the Elixir team for making it so easy and fun to do complex stuff and experiment on new things.
defmodule A do
def a <~ b do
{a, b}
end
def {a, [m, f]} ~> b do
apply(m, f, [a, b])
end
def {a, f} ~> b when is_binary(f) do
case f |> String.split(".") |> Enum.reverse() do
[f] ->
{a, String.to_atom(f)} ~> b
[h | t] ->
f = String.to_atom(h)
m = String.to_atom("Elixir.#{Enum.reverse(t) |> Enum.join(".")}")
{a, [m,f]} ~> b
end
end
def {a, f} ~> b when is_function(f) do
apply(f, [a, b])
end
def {a, f} ~> b do
apply(Kernel, f, [a, b])
end
end
# it allows you to write
5 <~"Integer.to_string"~> 2
5 <~"rem"~> 3
5 <~:rem~> 3
[a: 1] <~(&Enum.into/2)~> %{} # parenthesis are necessary due to op precedence
[a: 1] <~[Enum,:into]~> %{}
# or
enum_into = &Enum.into/2
[a: 1] <~enum_into~> %{}
# or, if you fancy ugly stuff
5 <~fn(a,b)-> rem(a,b) end~> 3
1
zkessin
Infix operators are great if you have 3-5 of them, but then you end up with a line of code like
a = b <=|=> c
and you think what in the world does that mean.
1
dwahyudi
I prefer f(x, y, z) over x f y z, thank you.
Pipe is there so you won’t have to write f(g(h(i(x), y), z), aa)
1
massimo
nobody’s trying to steal that from you
also operators works with two operands max, I’m sure you would prefer f(x,y) over f(x,y,z,x,w,k,j,t,o,flags_array)
I prefer the f(x) syntax as well, still there are situations where i think it could be of some help
row_id = ordinal_name(div(index, cols)) <> "_row"
row_id = (cols |> div(index) |> ordinal_name) <> "_row"
row_id = ordinal_name(index `div` cols) <> "_row"
I’m not trying to start a war on which way is the better one
let’s try to give functions a meaningful name
line_to(transpose_to(move_to(coords_for(x), y), z), aa)
could be written as
coords_for(x) |> move_to(y) |> transpose_to(z) |> line_to(aa)
coords_for(x) `move_to` y `transpose_to` z `line_to` aa
The greatest limitation of the infix notation is that it works when the function acts like an operator.
Pipes look better when stacked and are more useful in the general case.
I don’t see myself writing
record `insert_into` database
0
NobbZ
Have you considered this:
id_fragment = div(index, cols) |> ordinal_name()
row_id = "#{id_fragment}_row"
This is by far the most clear way to write that, plus/minus piping vs. calling in the id_fragment = … line.
When building strings one should try to replace function calls by variables that already have been bound to. Most of the time this makes the effort much more clear.
In most cases, infixing function names and also pre-fixing operators by using `` and () in haskell is often disturbing and requires additional brainpower to re-write the expression in the head to be as it would have been naturally written.
4
doma_dev
Dear all,
we’re maintaining witchcraft family of libraries in the wake of deprecations of some pre-defined infix operators.
Right now we’ve already removed some infix notation from the Control.Arrow modules, which makes the UX worse. It’s a sad concession to make, but we’re ready to make it.
However, <|> is now deprecated too, making us consider <~> for Alternative. The problem, however, is that we can’t use this new <~> from Alternative in modules that use <~> from other modules because qualified calls to infix functions don’t work:
iex(3)> alias Kernel, as: K
Kernel
iex(4)> "foo" <> "bar"
"foobar"
iex(5)> "foo" K.<> "bar"
** (SyntaxError) iex:5:7: syntax error before: 'K'
It would be very sweet if we got facilities to define custom arrows in Elixir. All the code to support it is there already, and it is absolutely needed even for ergonomic Alternative and Applicative.
Consider the following model example:
Given
def maybeLeft, do: {:left, {}}
def maybeRight, do: {:right, {}}
applicative-style function that branches depending on eihter:
def nimble(x) do
(maybeLeft *> pure("fail")) <|> (maybeRight *> pure("success"))
end
versus
def nimble(x) do
or_else(ap_right(maybeLeft, pure("fail"), ap_right(maybeRight, pure("success")))
end
The first snippet is clean, the second snippet is messy.
In general, when the operators encode branching or multiplying computation, pipe is insufficient.
At least one industrially validated usecase for this functionality is applicative-style combinatorial parsing. There are more, of course, but I think it is a sufficient argument for custom arrows.
Please note that it’s not to say that C+±style operator overloading is a good feature! The difference is that operators “apply right”, “apply left”, “apply” and “or else” are fundamental. Anything that is Applicative has “ap”-operators, and anything that is Alternative has “or else” operator. So it’s not about overloading operators, but rather about showing that some data structure has properties that allow us to use fundamental operators.
I’d like to also add that the argument for “adding ways to do things”, with all due respect, doesn’t hold water. We have macros in Elixir, which means that many peculiar behaviours can be implemented. A classical example of one is “conn” variable appearing out of thin air when we use get or post macro in Plug. Is it good UX? Yes. Is it confusing when one sees it for the first time? Also yes. I had junior devs ask me question “where does conn come from?”.
In concolusion, I think that there are many options in the solution space to enable this, including having a limited amount of infix operators, but allowing to call them in infix notation in a qualified mode (make Kernel.<> callable in the infix way). But I think that it’s rather natural to simply allow Elixir programmers to define their own operators using the following grammar:
opS = '<' | '>'
opC = '+' | '*' | '&' | '^' | '-' | '~' | '|'
operator = (opS (opS | opC)*) | ((opS | opC)* opS) | (opC opC opC+)
P.S.
To reiterate the point, compare once again:
opS = either(string('<'), string('>'))
opC =
either(string('+'), string('*'))
|> either(string('&'))
|> either(string('^'))
|> either(string('-'))
|> either(string('~'))
|> either(string('|'))
operator =
opS
|> followed_by(many(either(opS, opC)))
|> either(many(either(opS, opC)) |> followed_by(opS))
|> either(opC |> followed_by(opC, some(opC)))
with
opS = string('<') <|> string('>')
opC =
string('+') <|> string('-') <|> string('&') <|> string('^') <|>
string('-') <|> string('~') <|> string('|')
operator =
(opS <*> many(opS <|> opC)) <|>
(many(opS <|> opC) <*> opS) <|>
(opC <*> opC <*> some(opC))
P.P.S.
If this proposal is accepted, we’re more than happy to submit a PR!
1
rvirding
Creator of Erlang
Won’t that seriously complicate the understanding of other peoples code? And how should/would the formatter handle these things?
1
asianfilm
To back this up, Elm makes a special allowance for the custom infix operators used in its applicative-style combinatorial parsing library even when it removed the ability to introduce custom infix operators for libraries generally.
(I’ve been meaning to convert one of my Elm combinatorial parsers to Elixir to see how much expressiveness and clarity is lost when using its Nimble parser. And to compare speed.)
1