Wed Jan 7 14:01:23 CET 2004
"James Hague" <james@REDACTED> writes:
> Robert Virding wrote:
> >2. Many of the warnings generated by the
> >compiler have been chosen in an extremely
> >ad hoc fashion, they were deemed useful by
> >someone and easy to implement. There is
> >really no clear policy for what is checked
> >and what is not. I mean why check the
> >arguments to io:format and not a host of
> >other common library functions.
> I tried to make this point in an earlier message, though I may not
> have succeeded. I don't really want to see the compiler cluttered up
> with a lot of checks for things that may or may not be errors,
> especially when:
> 1. There are many more things that are not checked (for example, any
> place where a newbie types "x" instead of "X"). Trying to catch them
> all seems like a long and unproductive road to go down. (Okay, I
> once complained about list comprehensions without generators being
> quietly compiled, but I'd argue that's invalid Erlang.)
Our intention is not to try to catch all possible errors.
The new warnings I've added are emitted by the optimization passes.
Instead of silently removing a clause that cannot possible match,
a warning is produced. Thus, there is not a lot of extra code in the
There were many warnings in the OTP code for clauses that could not match.
Most of them harmless, of course, since the code is working, but the
redundant clauses are confusing for anyone reading the code.
I found a few redundant clauses in the compiler itself.
> 2. Simple, interactive testing catches all of these errors anyway,
> even the ones that aren't warned about.
IMO, everything that help you find more bug is useful. When working
against a tight dead-line, most people forget to do the simple test,
to "save time".
> Additionally, I think Erlang--both the language and implementation--
> are on the verge of becoming too complicated. I think both could use
> some streamlining. Adding ad hoc warnings is a step in the other
I see your point, but I consider the new warnings to be useful,
and they did not add much complexity to the compiler. Maybe reduced
the complexity, as I could clean up part of the code at the same time.
Björn Gustavsson, Erlang/OTP, Ericsson AB
More information about the erlang-questions