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

[Robert Baruch]

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):

-module(foo.bar.baz).
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  
qualified name.

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  
name qualification.


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  
issues.


Then again, what do I know -- my main programming language is Java :)

--Rob

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  
> auto-imported,
> we may break code that was written long before the BIF was introduced.
> That is bad.
>
> /Bjorn
> -- 
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>