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

[Gleb Vinogradov]

Let's compare `-spec` and `-behaviour` declarations.
Erlang compiler doesn't check `-spec` declarations and doesn't produce
warnings if function called with wrong parameters. Dialyzer does.
So, I think behaviour checks could be removed from compiler as well, and
should be placed in dialyzer. So behaviours of compiler and dialyzer will
be consistent - one tool compiles the code and doesn't care about
declarations, but another does.

Best Regards,
Gleb

2016-12-20 4:52 GMT+07:00 Michael Truog <mjtruog@REDACTED>:

> Based on the discussion of https://github.com/erlang/otp/pull/1274 there
> needs to be a discussion on the mailing list to determine if we can remove
> behaviour checking in the Erlang compiler, and to determine where the
> behaviour checking will be done in the future.
>
> Since the atomic update unit for source code in Erlang is a module, not an
> Erlang/OTP application, it seems best (to me) to avoid having the compiler
> attempt to process Erlang/OTP applications, unless many things were changed
> so that all Erlang/OTP application modules were versioned and updated
> together, possibly allowing the coexistence of separate versions of the
> same Erlang/OTP application.  Inlining across module boundaries has been
> discussed before (e.g., http://erlang.org/pipermail/er
> lang-questions/2015-December/086943.html https://github.com/erlang/otp/
> pull/1274 ), and pursuing inlining within an Erlang/OTP application seems
> best if the Erlang/OTP application is updated as one atomic update unit
> that is versioned together.
>
> The current Erlang behaviour checking is a simpler problem that is mainly
> about trying to determine where linting should take place. Much of the lint
> activity for Erlang source code occurs in dialyzer, so that seems like a
> natural place to move behaviour checking to (to me).  The reason we are
> talking about this is to make sure the Erlang compiler is a dependable
> executable that can be part of a dependable toolchain, since we want a
> software stack that can work together in a way where everything is as
> reusable as possible.  A compiler that sometimes fails due to a warning
> when ran with parallel execution would be undependable as part of a larger
> toolchain.  Having a toolchain that avoids monolithic development helps to
> pursue more efficient development, since each monolithic development effort
> is effectively a dead-end due to the replicated effort in each monolithic
> result (similar to rebar2 and rebar3 coexisting, and both being difficult
> to use in a separate build-system).  Having several smaller tools that are
> reusable helps to make sure everything can grow to fit any use-case
> (similar to how maven has grown in the Java ecosystem).  So, this may not
> fit into one email thread, but it does appear to require more discussion to
> move further.
>
> Best Regards,
> Michael
> _______________________________________________
> 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/20161220/caaa75c9/attachment.htm>