Subject: Re: [erlang-questions] Remove behaviour checking
from erl_lint (continued)



my opinion, 
if intent is to simplify components in tool chain such as compiler -> xref -> dialyzer ..... or some variationthen i agree that compiler should not check for any external deps. But in that case there should be added some standard tool to run that tool chain, because users don't want to spend much time on configuring things like that, and it should be default practice to run that tool instead just compiler. And if you have some specialneeds to skip some steps or just use single step, than you still have all this discreet tools available to use them as you want.But for that Dialyzer in my opinion should be heavily optimized. 
in a sense i see need for clear separation of tasks and responsibilities but on other hand i want default use case to be as simple as possible and also as strict as possible.
On Thu, Dec 22, 2016 at 1:13 AM, Richard A. O'Keefe <ok@xxxxxxxxxxxxxx> wrote:
Let me offer another perspective.

Once you add -type and -spec declarations to your Erlang code,
it becomes ASTONISHING that your code is not in fact type checked
by the compiler.

There is no other programming language that I use or have ever
used in which source code *with* type information isn't checked
by the normal compiler, to the extent that it *can* be checked
locally.

It is fatally easy to think that because you took care
to write -type and -spec and the compiler is silent that
your code is type correct, when it isn't.

Long term, we should not be shunting off ever more checking
from the compiler to the dialyzer; on the contrary, the
dialyzer as a separate tool should disappear.  There should
still be some compiler option to say how *much* checking is
to be done, but the default should be "I'll check everything
I can within the limits of what you've given me".

_______________________________________________
erlang-questions mailing list
erlang-questions@xxxxxxxxxx
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-questions@xxxxxxxxxx
http://erlang.org/mailman/listinfo/erlang-questions



Programming list archiving by: Enterprise Git Hosting