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

[Michael Truog]

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/erlang-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