[erlang-questions] lists:reverse/1 as a built-in function
Mon Jan 15 19:53:03 CET 2007
Personally, I'd like to decouple the "BIF problem" from the "import
problem", like this:
Use Java-like package rules in Erlang, applied like this:
(in file baz.erl):
example_function(Arg) -> false.
foo.bar is the package name. baz is the "class" name. If you call
example_function(Arg) inside baz.erl, you don't need to use a fully
If you call example_function(Arg) inside an erl file declared as -
module(foo.bar.X) then you need to call it as baz:example_function(Arg).
If you call example_function(Arg) anywhere else, you need to either
call it as foo.bar.baz:example_function(Arg), or you need to -import
(foo.bar), and then you must call it as baz:example_function(Arg).
The reason that I call baz the "class" name is that I'm thinking of
functions declared in module X as equivalent to Java's static
functions of a class X. The rules above should duplicate the
essential parts of the Java name resolution.
Once these rules are in place, the next thing is to allow any
functions declared in the erlang module to be used without fully
qualifying the name. Thus, a function foo(Arg) declared in erlang can
be called as foo(Arg) in any module. This is the equivalent of
"java.lang" in Java, except messier because the erlang module is not
further subdivided into related groups of functions. >:(
Finally, document well which functions are BIF's. This is the
equivalent of the "native" keyword in Java, except of course you
don't have the ability to declare a native function in a module. If a
BIF happens to be in the erlang module, you can use it without fully
qualifying the name. If a BIF is not in the erlang module, you must
qualify the name according to the package rules above. That is, a BIF
is treated no differently from any other function when it comes to
This solution decouples the "BIF problem" from the "import problem".
If a function becomes a BIF, programs would not have to change.
To transition, the next version of the compiler could have two modes,
one in which the package rules are followed, and one where the old
package rules are followed, but spits out deprecation warnings. The
compiler version after that would not support the old package rule mode.
Yes, it will break existing applications... but then they could
always use the old version of the compiler, which, presumably, they
used to create the original application. If they want to upgrade to a
new version of the compiler, they have to fix all of their deprecated
Then again, what do I know -- my main programming language is Java :)
On Jan 15, 2007, at 3:48 AM, Bjorn Gustavsson wrote:
> The current behaviour would be fine if it was decided once and for all
> which functions are BIFs, and we never added new BIFs.
> Unfortunately, we do add new BIFs, and if we choose to make them
> we may break code that was written long before the BIF was introduced.
> That is bad.
> Björn Gustavsson, Erlang/OTP, Ericsson AB
> erlang-questions mailing list
More information about the erlang-questions