[erlang-questions] lists:reverse/1 as a built-in function

[Robert Virding]

Thomas Lindgren wrote:
> --- Robert Virding <robert.virding@REDACTED> wrote:
> 
>>So with this in mind it is not really strange that
>>BIFs are 
>>auto-imported, and have priority over "normal"
>>functions defined in 
>>modules; they are part of the language. It is
>>perhaps unfortunate that 
>>we allowed definition of functions with the same
>>name and arity as the 
>>auto-imported ones.
> 
> 
> It might have seemed like a good design choice at the
> time, but note that auto-import (with "override") has
> several unfortunate ramifications, which is why it
> should be aged out. As Richard mentioned, one such
> consequence is the difficulty in extending the set of
> BIFs.

Sorry I think there is definitely a difference in stature between 
functions which are part of the language, BIFs like spawn and link, and 
normal user defined functions. If I redefine spawn then I have changed 
the semantics of Erlang, just as if I were to allow modifying how 
receive or ! works. Just because they have a special syntax does mean 
that they are more fundamental than spawn or link. The reason we did not 
  define a special syntax for them was because they do not need it, and 
because what a language does NOT need is a lot of unnecessary extra 
syntax. But we can make operators for the lot of them and the problem 
will be solved.

> Standardizing the set of functions implemented in C
> doesn't sound like a viable long term solution (nor
> does standardizing the set of overridden functions).
> Disallowing functions with the same names as builtins
> doesn't sound like a very good design choice either.
> Do note that there already is a simple,
> straightforward option that does the right thing.

I never said we should standardise the set of functions implemented in 
C, just that we should find a name for functions which are implemented 
in C but not part of the language. Using the name BIFs for everything 
does not show the difference in stature of the functions. I have no 
problems with choice functions from the standard libraries being 
implemented in C, it is a question for the development team to decide 
which functions are worth the extra effort, but there should definitely 
not be a coupling between how functions are implemented and how they are 
called. Just because lists:append/2 and lists:reverse/2 (not /1 if I 
remember) are implemented in C does not mean you should be able to call 
them with just append and reverse.

Robert