[erlang-questions] Type inference in Erlang [WAS: Re: The compiler "eats" structures which are not separated by commas]

[Kostis Sagonas]

On 04/23/2012 10:07 AM, Ulf Wiger wrote:
>
> On 23 Apr 2012, at 08:25, Kostis Sagonas wrote:
>
>> On 04/23/2012 04:39 AM, Robert Virding wrote:
>>>
>>> Type inferencing in erlang doesn't work. Unfortunately. There are too many places where it breaks down to be useful, for example message passing and code loading. There were attempts in the 90's by people much more knowledgeable than we were on this.
>>
>> OMG!
>> ...
>> Please think before you write statement that look authoritative but are plainly wrong.
>
> Of course, there is always a balance between servicing the community with vivid discourse and protecting your reputation by never risking being wrong.
>
> May I suggest that Robert's main mistake was using the word 'useful' - or specifically not clarifying the context.

Well, that's not it. Please re-read his post. His post started with an 
authoritative statement: "Type inferencing in erlang doesn't work." 
Sorry, but this is plainly wrong. Then it continued about the "too many 
places that it (type inference) breaks down to be useful" stating 
"message passing and code loading" as some of the reasons for this. As 
explained in my post, handling the interaction of type inference with 
code reloading is just an engineering issue -- by no means trivial but 
an engineering issue nonetheless.

Finally, to give more evidence for this claim Robert mentioned "attempts 
in the 90's by knowledgeable people". If I took this last statement 
literally, I would probably find it a bit insulting -- I don't because I 
am sure that Robert did not mean it this way.

Anyway, I will repeat myself: *there is no fundamental reason for type 
inference in Erlang not to work*; there are only engineering and still 
(erroneous) community perception reasons.

> Obviously dialyzer is (extremely) useful, but there is a reason why it's off-line and doesn't actually give compilation errors, but merely advice.

Well, no. This is also a wrong statement. The reason why dialyzer is 
off-line is mainly historical (it started as a separate tool) but also 
related to the fact that it is typically more effective when analyzing a 
complete application rather than a single module. But fundamentally 
there is actually no reason why dialyzer should remain an off-line tool, 
especially if the BEAM compiler gets extended to take a set of module 
rather than a single module as input.

Anyway, it's really a matter of somebody (at Ericsson?) adding a hook to 
it in the compiler, perhaps via an appropriate option. As to whether the 
results of dialyzer's analysis will be just warnings or compiler errors 
it's just a matter of preference and of the community reaching consensus 
on this.

(I am guessing the community may not be ready for this yet. For the time 
being, we have the "warnings_as_errors" compiler option.)

But the whole thing can be done in a couple of weeks. Really.

Kostis