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

[Richard O'Keefe]

On Jun 15, 2010, at 7:17 PM, Mikael Pettersson wrote:

> Richard O'Keefe writes:
>> No, the fact that a call is a remote call does NOT make it a
>> call to a function OTHER THAN THE FUNCTION IT CALLS.
>
> Er, that's obvious.

If it's that obvious, why have people been arguing against it?

>
>> In this example, the function that is called is foo:bar/1.
>
> Yes.  But foo:bar/1 is not necessarily the same code as the
> "bar/1 here before us".

I have already answered that point, at length and repeatedly.
It's the same *module* whether we reload it or not.
It's the same *function* whether we reload it or not.
It might (or might NOT) be a different version of the *code*,
but that's another thing.
Right now, in the code before is, there is a function definition,
and a call which, if executed, would invoke *THAT* definition and
not some other entirely imaginary definition.

The claim that the compiler makes is a claim about the code as it
stands, not about some non-existent flying spaghetti module.

You could with equal logic justify the compiler warning on each
and every remote call: 'Beware: this may destroy life on Earth.'

Please, I do know what remote calls do in Erlang, and I do know
about hot loading.  Don't try to teach your grandfather to suck
eggs.  And don't bother with Scheme examples: I've even written
a Scheme compiler.  I know Scheme semantics too.

Even in Scheme, a call to some-global is a call to (whatever is
the current state of) some-global, not a call to some *other*
function.