Does Elixir accept PRs that wrap Erlang functionality?

[scottswezey]

I spent a while implementing Erlang’s :lists.prefix in Elixir today, only I wasn’t aware it existed in Erlang. So now I’m curious if the core team generally accepts PRs that wrap Erlang functionality. I wouldn’t mind contributing some of this “missing” functionality, if the PRs would be considered. Does anyone know? Should I ask the elixir-lang-core mailing list instead?

My arguments for wrapping Erlang functions in Elixir:

• Similar functions, like Elixir’s List.flatten/2 and List.foldl/3, already exist and delegate to Erlang.
• It would mostly require rewriting the specs, docs, and tests. That sounds simple enough to me. (But I could be wrong.)
• Documentation in Elixir’s modules is more visible than Erlang’s. I think that is inherently “better,” even though Erlang can be called directly.

The potential downside is maintaining the code, should it ever change in Erlang.

[hauleth]

Sometimes yes, sometimes no, it depends. In general Elixir try to avoid “plain delegation” to the Erlang modules and unless there is some wrapping/argument reordering/backward compatibility requirements then it is better to just use OTP modules directly (Ockham’s law in practice).

@scottswezey

Similar functions, like Elixir’s List.flatten/2 and List.foldl/3, already exist and delegate to Erlang.

Some of them may be compatibility reasons.

@scottswezey

It would mostly require rewriting the specs, docs, and tests. That sounds simple enough to me.

Simple, but brings unnecessary maintenance burden on core team.

@scottswezey

Documentation in Elixir’s modules is more visible than Erlang’s. I think that is inherently “better,” even though Erlang can be called directly.

I disagree. It is a little bit harder to start, but Erlang documentation is superb resource of knowledge, and with little tooling it is no harder to browse than Elixir documentation (I am talking only about Erlang/OTP docs, not EDoc output which for some reason is completely different).

[josevalim]

For modules that already exist, we would likely accept such PRs to complement them. For example, the List module started as a complement to Enum for list specific functions and to provide a zero-indexed API. However, if a PR is to add a wrapper for whole new modules, such as :binary or :ets, then the answer is likely no exactly because you can use them directly.

PS: note in this particular case there is List.starts_with?/2.

[scottswezey]

Thank you both for letting me know about the PRs policy. It sounds like what I had in mind would be better off as a separate package, if it needs to exist at all.

I can’t believe I missed List.starts_with?/2.