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

Attila Rajmund Nohl attila.r.nohl@REDACTED
Fri Jun 4 11:29:11 CEST 2010


2010/6/4, Richard O'Keefe <ok@REDACTED>:
> There is currently a discussion going on in the SWI Prolog mailing
> list about the way user code can break when a new operation is
> added to the system.  Alan Baljeu takes the reasonable position that
>
> 	What's needed for stability ... is ...
> 	Whatever I define within a module
> 	is the definition used within [that] module.
> 	The local [operations] supersede imported [ones].
> 	Warn if something is shadowed, but allow it.
>
> I was about to gloat about Erlang getting this right, and then I
> thought I had better try it.
>
> Consider the following module.
>
>       1  -module(foo).
>       2  -export([bar/0]).
>       3
>       4  bar() -> spawn(fun (X) -> X+1 end).
>       5
>       6  spawn(F) -> F(41).
>
> where we're expecting foo:bar() to return 42.
> erlc reports
>
> /foo.erl:4: Warning: call to spawn/1 will call erlang:spawn/1; not
> spawn/1 in this module
>    (add an explicit module name to the call to avoid this warning)
> ./foo.erl:6: Warning: defining BIF spawn/1
> ./foo.erl:6: Warning: function spawn/1 is unused
>
> The second message is clearly WRONG:  this _can't_ be defining the
> built-in function erlang:spawn/1 because this isn't the erlang:
> module.

I think that second message is right. The message is not about
erlang:spawn, but a function that could be accessed simply by the name
"spawn" (and it happens to be a BIF). The root cause of the problem is
that many functions from the erlang module are "auto-imported", but if
my memory serves correctly, this is being addressed by the OTP team.


More information about the erlang-questions mailing list