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

[Robert Baruch]

On Jan 16, 2007, at 5:25 AM, Thomas Lindgren wrote:

>
> First of all, I'd recommend you have a look at
> Erlang's packages, which are fairly Java-inspired, as
> far as I know.

Yeah, I've seen that already. It's okay, but I don't think it goes  
far enough. Again, it seems to me that modules are useful for  
grouping related functionality (such as functions about lists, or  
functions about strings), and so I considered a module as  
conceptually equivalent to a Java class with all static methods, and  
an Erlang package name is a way of grouping modules, just as a Java  
package name is a way of grouping Java classes.

In Java, if you import, say, java.io.InputStream, then you would  
still have to refer to static InputStream methods using  
InputStream.method() and not just method().

Similarly, if you import java.io.*, that allows you to refer to any  
class X in java.io as X instead of as java.io.X.

Based on that idea, -import(foo.bar.baz) where baz is a module name  
would allow you to use baz:function(), but should not allow you to  
use function(). This is the equivalent to Java's import  
java.io.InputStream.

Also, you get the added advantage that -import(foo.bar) will allow  
you to access any module X in package foo.bar using X:method()  
instead of foo.bar.X:method(). This is the equivalent to Java's  
import java.io.*.

>
>> 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).
>
> What if example_function/1 is imported into module m
> and also is defined in m? If I (locally, in m) call
> example_function(1), which function would this
> proposal invoke?

If example_function/1 is imported into module m, then it must be  
imported from some module X. Then you must call X's example_function/ 
1 as X:example_function/1, and m's function would just be called as  
example_function/1. The names would not clash because they exist in  
different namespaces.

>
> For example:
>
> -module(m).
> -compile(export_all).
> %% f/1 is auto-imported
>
> f(1) -> ok.
>
> g(X) -> f(X). %% which f/1 is called?

You could handle this in one of two ways:

(1) This would be a compile-time error. At the time that you declare f 
(1), f/1 has already been declared because it was auto-imported. This  
is pretty strict, but requires the least number of compilation passes.

(2) The auto-imported f/1 is not available in this module without  
full qualification. Thus, f(X) will always call m:f/1, and to use the  
"auto-imported" f/1, you have to fully qualify it (as, for example,  
erlang:f/1). This would require two-pass compilation, since first you  
have to determine the local names that are declared, then you have to  
resolve the calls based on the declared local names.

Java doesn't really have an equivalent to this issue, because there  
is no global namespace for methods to pollute.  All methods exist in  
their class's namespace, and the only auto-import done is  
java.lang.*, which still means you have to use X.method when calling  
a method in java.lang.X.

>
>> The reason that I call baz the "class" name /.../
>
> Not to sound too bad-tempered, but please don't do
> that :-) The Java terminology doesn't quite
> transplant, so it's liable to just be confusing.

Yeah, you're right :) I'll try to stick to "package and module" when  
talking about Erlang :)

But just in case people are getting confused, here's my dictionary :)

Java class -> Erlang module
Java package -> Erlang package
Java method -> Erlang function

--Rob