[erlang-questions] lists:reverse/1 as a built-in function
Tue Jan 16 17:50:45 CET 2007
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
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
>> 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
> 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
> For example:
> %% 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
More information about the erlang-questions