No, it’s not. Compiler is able to inline and analyze types only when call’s context and the function which is called are in the same module. Plus, protocols require structure key access which also takes time. I will provide a benchmark in a minute
hst337
lpil
Creator of Gleam
If functional combinators are too expensive to use why do we use the Erlang lists module or the Elixir Enum module? They are entirely made of higher order functions.
The BEAM is designed for functional programming. It would indicate a great incompetence on behalf of the maintainers if function calls were expensive on a functional virtual machine.
0
hst337
:lists module leverages special kind of inlining. But Elixir’s Enum module doesn’t, and that’s a problem I am solving in my optimizing Elixir compiler.
By the way, @sabiwara had a library called Enumancer which solved this exact problem, but with macros and in Elixir
Yes, but functional programming is not about algebraic types or even static typing, it is just about functions. The very first functional language ever existed had no idea about flatMaps or even functors.
It is not an incompetence, Erlang and Elixir are not top notch functional languages with most bleeding edge ideas around functions. They are not even built around lambda calculus.
They were just designed for different problems. Thus, function calls are expensive to provide ability to change code in runtime as fast as possible
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
I think this conversation is suffering from a lack of a definition about what counts as small or fast here. These are relative terms, and for people say, returning HTTP results, the overhead of a remote function call vs a local one is indeed small. For a hot loop processing a million records, maybe it isn’t small.
5
hst337
Here’s the benchmark
Mix.install [:benchee]
defmodule Either do
def left({:ok, result}, func), do: func.(result)
def left({:error, reason}, _func), do: {:error, reason}
def right({:error, reason}, func), do: func.(reason)
def right({:ok, reason}, _func), do: {:ok, reason}
end
defmodule X do
import Either
def monadic(x) do
{:ok, x}
|> monadic_inc()
|> monadic_inc()
|> monadic_inc()
|> monadic_compare()
|> monadic_inc()
end
def monadic_inc(x) do
left(x, & {:ok, &1 + 1})
end
def monadic_compare(x) do
left(x, fn
x when x > 0 ->
{:ok, x}
_ ->
{:error, :too_small}
end)
end
def regular(x) do
x = x + 1
x = x + 1
x = x + 1
if x > 0 do
x = x + 1
{:ok, x}
else
{:error, :too_small}
end
end
end
X.monadic(-4) == X.regular(-4) || raise "Wrong"
Benchee.run(%{
"monadic" => fn -> X.monadic(-4) end,
"regular" => fn -> X.regular(-4) end
})
"""
Name ips average deviation median 99th %
regular 8.70 M 114.97 ns ±875.76% 99 ns 265 ns
monadic 2.71 M 369.24 ns ±12527.05% 151 ns 632 ns
Comparison:
regular 8.70 M
monadic 2.71 M - 3.21x slower +254.27 ns
"""
And it is built around simplest either-style tuple. Libraries like Algae would be even slower
2
lpil
Creator of Gleam
This isn’t a benchmark of functional combinators, this is a benchmark of integers inside tuples against bare integers.
0
hst337
Yes, and this benchmark shows that overhead of combinators is too big to use them for control flow, since it is much easier to just hand-roll all conditional branching
0
lpil
Creator of Gleam
You misunderstand me, my suggestion was to use functional combinators, not to use functional combinators in additional boxing with tuples.
You can (and should) use functional combinators without boxing (see the lists and Enum module for example). I am in no way suggesting that a library like Algae will have comparable performance.
Functional combinators and Haskell style boxing + monads are not the same thing.
0
hst337
lpil
Creator of Gleam
At no point have I stated one should be using Either or monads in general.
I assure you, this was not my suggestion.
0