[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