CODEWITHSUNDEEP
erlang
Adam Gent
Adam Gent

Reputation: 49085

Why does Erlang have arity in its imports?

I find Erlang's module arity import /n where n is the number of arguments rather bizarre.

In Java and various other languages you can do something like:

import static com.stuff.Blah.myFunction;

Which will import all overloaded Blay.myFunction(..) regardless of parameters.

Besides I guess being explicit why did the language designers decide this was a good idea (I'm not trying to criticize the language... just curious)?

Upvotes: 1

Views: 649

Answers (3)

rvirding
rvirding

Reputation: 20916

You should be aware of what importing functions in Erlang really does. It is a pure textual transformation. If I do an -import(foo, [bar/1,baz/2]). it means that when I write a call like bar(5) or baz(a, 3) the compiler transforms these to foo:bar(5) and foo:baz(a, 3). That is all it does, nothing else. It doesn't check anything:

  • It doesn't check if the module foo contains the functions bar/1 or baz/2.
  • It doesn't even check if the module foo exists.

Really all it does is hide that you are calling a function in another module. That is why the recommendation from experienced Erlangers is "don't use it". It was a mistake. Unfortunately it is much easier to add stupid things than to get rid of them so we were never able to remove it.

"Does it have to do with code swapping?"

Yes, sort of. The unit of all code handling in Erlang is the module. So you compile modules, load modules, purge and delete modules. This means that there are no inter-module dependencies at all in the system and the compiler makes no assumptions about other modules when it is compiling a module. No assumptions are made that the environment in which a module is compiled will be the same in which it is run. That is why it is at runtime the system checks whether the function you are trying to call in another exists, or even if the module itself exists. That is why the import was a purely textual transformation.

Upvotes: 10

Dann Martens
Dann Martens

Reputation: 31

Erlang was originally developed in Prolog.

In Prolog, the arity adds additional meaning to what you consider to be the 'arguments, as I understand from a function' in a procedural programming language. But that model does not apply here.

The so-called clauses 'married(X,Y).' and 'married(X,Y,Z).' imply a different kind of relationship 'married', which can be declared as married/2 and married/3.

In procedural programming, 'add(a,b)' or 'add(a,b,c)' are intended to generate the addition of a different number of arguments. That's not immediately the case in Prolog, where it is possible to have the relationship 'a and b, added' or 'a, b and c, added' mean something else. Needless to say, Prolog allows you to declare 'add' as you would expect a function would do. But it allows for more. More available meaning, means more need to control it.

And as in any module system, selecting what you want to expose to external clients makes sense: hence the declaration of arity.

Upvotes: 3

Alexey Romanov
Alexey Romanov

Reputation: 170723

Does it have to do with code swapping?

Kind of. The modules in Erlang are compiled separately (which is part of what allows code swapping), unlike Java classes, so the compiler doesn't know how many versions of the imported function with different arities exist. It could assume that all calls of a function with the given name come from the same module, of course, but the designers likely decided it wasn't particularly useful.

In fact, you rarely want to use imports at all, at least in my experience, just as you rarely use static imports in Java. Just write module:function, like Class.staticMethod.

Or does it have to do with hiding guard methods for recursion?

No, since not importing functions doesn't hide them in any way.

Upvotes: 1

Related Questions