[erlang-questions] Type inference in Erlang [WAS: Re: The compiler "eats" structures which are not separated by commas]
Mon Apr 23 14:49:00 CEST 2012
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.
>> 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
(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.
More information about the erlang-questions