<div dir="ltr"><div>Let's compare `-spec` and `-behaviour` declarations.</div><div>Erlang compiler doesn't check `-spec` declarations and doesn't produce warnings if function called with wrong parameters. Dialyzer does.</div><div>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.</div><div><br></div><div>Best Regards,</div><div>Gleb</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-12-20 4:52 GMT+07:00 Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Based on the discussion of <a href="https://github.com/erlang/otp/pull/1274" rel="noreferrer" target="_blank">https://github.com/erlang/otp/<wbr>pull/1274</a> 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.<br>
<br>
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., <a href="http://erlang.org/pipermail/erlang-questions/2015-December/086943.html" rel="noreferrer" target="_blank">http://erlang.org/pipermail/er<wbr>lang-questions/2015-December/<wbr>086943.html</a> <a href="https://github.com/erlang/otp/pull/1274" rel="noreferrer" target="_blank">https://github.com/erlang/otp/<wbr>pull/1274</a> ), 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.<br>
<br>
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.<br>
<br>
Best Regards,<br>
Michael<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br>
</blockquote></div><br></div>