[erlang-questions] warnings for "not recommended" usage of language constructs

[Vlad Dumitrescu]

Hi!

On Sat, May 17, 2014 at 3:58 PM, zxq9 <zxq9@REDACTED> wrote:

> On Saturday 17 May 2014 11:38:39 Vlad Dumitrescu wrote:
> > Related to my previous post about literal whitespace characters, I wonder
> > if it might be a solution acceptable to most (all?) people to add
> compiler
> > options to control if such usage will emit warnings or not. This way one
> > can choose to go on as before or to get informed when there are
> > controversial constructs in the code.
> >
> > At the moment I have two suggestions for such constructs:
> >
> > - literal whitespace characters
> > - "ill-behaved" macros
>
> The more information we can get from the environment (build tools,
> compiler,
> runtime, etc.) the better. Warnings, build status, dead code locations,
> etc.
> The more the better. This is especially true in controversial cases like
> the
> literal whitespace one that could so easily go unnoticed.
>
> I'm particularly fond of having the option of a logically independent lint-
> type pre-processing step that checks if code is conforming to whatever the
> community canon is and raises warnings (or interrupts the build, etc.)
> before
> the compiler gets a hold of the code. The reason I like this way more than
> making everything a compiler warning is that it leaves the compiler
> implementation logically dependent only on the language definition, and the
> linting process free to embrace as much arbitrary knowledge from the
> community
> as the implementers have time for. It also leaves the option of different
> linters/rules to be inserted in that step instead of only leaving room for
> the
> One True Way and drastically limits the size of the compiler manpage by
> preventing compiler option proliferation over time.
>

The linter is already separated from the compiler, it is called as a
separate stepfrom the compile proper. It's good idea to make it modular, so
that linting steps can be added even by third parties. The current
implementation looks like it just goes through the different checks
sequentially, so it shouldn't be a huge amount of work to extract the steps
to separate modules. I can look into it.

regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140517/3fe6326b/attachment.htm>