[erlang-questions] Overriding built-in functions in a module
Igor Ribeiro Sucupira
Fri Jun 4 07:53:13 CEST 2010
On Fri, Jun 4, 2010 at 2:18 AM, Richard O'Keefe <> wrote:
> On Jun 4, 2010, at 3:39 PM, Igor Ribeiro Sucupira wrote:
>> On Thu, Jun 3, 2010 at 10:00 PM, Richard O'Keefe <> wrote:
>>> So let's do what the first error message says:
>>> * 4 bar() -> ?MODULE:spawn(fun (X) -> X+1 end).
>>> m% erlc foo.erl
>>> ./foo.erl:6: Warning: defining BIF spawn/1
>>> ./foo.erl:6: Warning: function spawn/1 is unused
>>> There's an explicit call there, how can it not be used?
>> This was a little bit unrelated to the topic. Given that you can't
>> call a non-exported function with that syntax, that code is certainly
>> not calling the local fun spawn/1, since it's not exported.
> Note that I wasn't suggesting that the call should be *allowed*,
> only that it is *there*. There's a big difference between
> "there are NO calls to this function" and
> "the calls to this function won't be allowed at run time because
> the function is not exported."
Although I disagree with this opinion, I recognize that deciding if
"the call is there" depends on how far one thinks the compiler should
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.
> In short, I am not quarreling with the decision to report an
> error here, only commenting that the error message is extremely
"The secret of joy in work is contained in one word - excellence. To
know how to do something well is to enjoy it." - Pearl S. Buck.
More information about the erlang-questions