[erlang-questions] Overriding built-in functions in a module

[Richard O'Keefe]

On Jun 4, 2010, at 5:53 PM, Igor Ribeiro Sucupira wrote:
> Although I disagree with this opinion, I recognize that deciding if
> "the call is there" depends on how far one thinks the compiler should
> go.

The issue wasn't "how far the compiler should go" but
"what the compiler should SAY".  It is simply that error messages
should not be misleading.

In the case at hand, when there IS a call to ?MODULE:f/n
a compiler that says ?MODULE:f/n is unused is *WRONG*.
Period.
If on the other hand the compiler says there is no *LOCAL*
call to f/n, then it is saying something true.

> I believe the compiler has a coherent behavior in that case: function
> calls with module syntax are only "resolved" at run time, so deciding
> the call is there in that example would require the compiler to treat
> as a special case the calls that happen to be to a module with the
> same name as the one being compiled.
> The compiler opts to not do that extra analysis of function calls,
> since it doesn't absolutely need to. Maybe this is not as "clever" as
> it could be, but I think it is a coherent behavior.

No, because what the compiler *says* (this function is not used) is
not consistent with what the compiler has *done* (checked whether
there are any local calls).  In fact I have found error messages from
the compiler about functions not being used to be wrong vastly more
often than they are right, simply because other errors in a module
often calls to be overlooked.

So instead of saying something about f/n not being *used* ("anywhere"
being Griceanly implied) the compiler should say that
** no local calls to f/n were detected
>
>> In short, I am not quarreling with the decision to report an
>> error here, only commenting that the error message is extremely
>> misleading.

This is a general principle about error messages.
A compiler has checked whether some condition C holds or not.
The error message should relate to condition C, not to some
other C'.
As a general rule, compilers should not try to guess *why*
condition C was violated; I've found such guesses to be wrong more
often than right.  But they should be clear, truthful, not misleading
about why they are complaining.