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

Igor Ribeiro Sucupira <>
Wed Jun 9 07:06:33 CEST 2010

On Tue, Jun 8, 2010 at 10:53 PM, Richard O'Keefe <> wrote:
> On Jun 4, 2010, at 6:25 PM, Raimo Niskanen wrote:
>>>> 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
>> But there *are* no calls to the local function spawn/1.
> Yes there is, it's just not a *local* call.
>> The local function spawn/1 will never be used and
>> that is what that warning says.
> No it isn't, really.

This is quite clearly what Raimo said:
./foo.erl:6: Warning: function spawn/1 is unused

Also, I think it was a crucial point: the compiler's analysis decided
(it wasn't a guess) that the function you're compiling will never be
executed. You may argue that "usage" and "call" are more synonyms than
"usage" and "execution", but then we could argue forever.

As I can argue that the function you're are compiling will never be
called (and this is actually my point of view). You disagree, but what
I see in the code foo:spawn(...) is a call to an exported function,
called spawn, with arity 1, on module foo. Maybe my mind is affected
by the times I had to plan and perform code upgrades, but I really
don't see a call in that code to the function you are compiling.
Anyway, you can throw this last paragraph away, because what I wanted
to stress is above it.

Best regards.

>  If the error message said
>        There is a remote call to local function spawn/1
>        but it is not exported so it can never be used
>        that way.
> I might agree with you.

More information about the erlang-questions mailing list