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

[Richard Carlsson]

James Hague wrote:
> lists:reverse/1 is already a function written in C, but is there any
> reason it can't be put on equal footing with length/1, size/1,
> integer_to_list/2, and so on.  Surely reverse is the most commonly
> used stdlib function, so why not promote it to a true built-in, so
> there's no need to prefix it with "lists:"?

The set of auto-imported functions ("built-in" is a much wider concept)
is not possible to extend without breaking backwards compatibility.

Once upon a time, for some random reason, the unfortunate choice was
made to let the auto-imported functions take priority over any locally
defined function of the same name. Hence, adding e.g. lists:reverse/1
to the set would cause it to be called instead of any user-defined local
reverse/1. Although the compiler would warn about the local, conflicting
definition (which is not used), the program would still compile, but get
a different behaviour. It might be a rare thing for people to define a
local function called reverse/1, but this kind of change is usually
unacceptable for many users.

It would be possible to reverse the priority of auto-imported and local
functions in a new version of the compiler, with an option to use the
old behaviour, but it seems to me that even this kind of change is
politically difficult. (There are several other useful language changes
that could be handled the same way, if users would accept it.)

I'm pretty sure that such compiler switches and incompatibilities are
not seen as much of a problem (compared to the advantages of getting an
improved language) by individual users and hobby programmers, but those
professionals out there who are maintaining large systems might have
completely different opinions about it, and I'd really like to hear
what they have to say. Any takers?

     /Richard