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

Karlo Kuna kuna.prime@REDACTED
Thu Dec 22 01:54:15 CET 2016


my opinion,

if intent is to simplify components in tool chain such as compiler -> xref
-> dialyzer ..... or some variation
then 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 special
needs 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@REDACTED>
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@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161222/62e5ad76/attachment.htm>


More information about the erlang-questions mailing list