[Proposal] Add type inference (etc) to the compiler

[Rich Morin]

Given that the Elixir language has largely stabilized, it may be time
to consider ways to make the compiler a bit more helpful. For example,
it might be possible for some sort of type inference to detect the
following sorts of bugs at compile time:

x = :abc
x + 1

f = 4
f.(1)

bar_fn = fn a, b -> a + b end
bar_fn.(c)

FWIW, this proposal stems from a discussion on Elixir Forum:

"Why doesn’t Elixir check the arity of anonymous function calls"
https://elixirforum.com/t/why-doesnt-elixir-check-the-arity-of-anonymous-function-calls

-r

[José Valim]

Hi Rich,

While it is completely OK to submit feature requests to this mailing list, the feature you are requesting would take literally years of work to be implemented in a way that it is useful for anything beyond obvious examples such as "bar = :bar; bar + 1".

A proposal on this topic would have to consider all of that, discuss approaches, alternatives, literature, pros/cons, etc.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/51EA85AD-EDE5-43AE-9BB0-340A94D79C3D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Rich Morin]

> On Jun 25, 2019, at 13:17, José Valim <jose....@plataformatec.com.br> wrote:
>
> While it is completely OK to submit feature requests to this mailing
> list, the feature you are requesting would take literally years of
> work to be implemented in a way that it is useful for anything beyond
> obvious examples such as "bar = :bar; bar + 1".

I don't think the situation is quite that dire, but it also sounds like
this isn't an appropriate venue for the sort of speculative discussion
I'd like to pursue. So, I'll head back to the aforementioned topic on
Elixir Forum (https://elixirforum.com/t/23401).

-r

[José Valim]

It is completely fine to have the discussion here. My point was only that there is quite more work to be done in order to consider this a proposal and this is a complex topic, so the engagement may be poor until more information is available.

--

[Rich Morin]

> On Jun 25, 2019, at 22:15, José Valim <jose....@plataformatec.com.br> wrote:
>
> It is completely fine to have the discussion here. My point was only that there is quite more work to be done in order to consider this a proposal and this is a complex topic, so the engagement may be poor until more information is available.

Thanks for the clarification (and cautionary advice :-).

Thinking a bit harder about the issue, I realize that my typical use case involves
defining lambdas, binding them to names, and then passing them into functions that
are embedded in pipelines, eg:

review_fn = fn {path, _title, _precis} -> ...
...
|> Enum.filter(review_fn)

In this scenario, I can't think of any reasonable way for the compiler to check
the lambda's arity, let alone its argument types. However, it does seem that a
tool such as Dialyzer should be able to detect some discrepancies.

So, as a test, I tried adding another parameter to the lambda definition:

review_fn = fn {path, _title, _precis, _foo} -> ...

However, Dialyzer did not detect this. Can someone explain why this might be and
whether this reflects a fundamental limitation of some sort?

-r