local renaming with a module attribute

[Fred Hebert]

I would like to discuss the idea of adding a new module attribute allowing
to rename a module when doing explicit external calls (local renaming, if I
can coin the term). The attribute -rename(long_module_name, name) would
allow the programmer to use 'name' instead of 'long_module_name' inside a
given module.

The reason for this is the regular necessity to manually 'namespace' modules
when writing an application. Given the fictive application 'robot', the
application structure fits best under the following fictive modules:

robot.erl   -- interface functions to control your robot
brain.erl   -- fsm that represents the robot brain
sup.erl     -- app supervisor
mapping.erl -- allows the robot to represent its own map to navigate
speech.erl  -- allows voice recognition

Under the current system, we need to avoid possible name clashes and instead
write the modules as:

robot.erl
robot_brain.erl
robot_sup.erl
robot_mapping.erl
robot_speech.erl

Which then gets repeated on every function call that might follow from
within the application itself.

Most of these namespaced modules are necessary only to prevent conflicts and
add no information to a program, only cruft to mentally skip over.

The new module attribute (say, '-rename(Old, New).') would allow to change:

some_fun(X) -> robot_mapping:funcall(X+1, robot_speech:empty()) end.

to the following:

-rename(robot_mapping, mapping).
-rename(robot_speech,  speech).
some_fun(X) -> mapping:funcall(X+1, speech:empty()) end.

Which allows us to retain all useful information about a module without the
manual namespacing or requiring to import the functions.
A naive implementation could simply expand all static 'New' external calls
to the 'Old' value for everything to be transparent to the outside world.
----
Local renaming overlaps the current packages system (
http://www.erlang.se/publications/packages.html) a bit in its approach to
namespace. However, there are a few noticeable difference, two of which are:

   - packages are based on the directory structure of the source files.
   Local renaming is restricted to a single module at a time and bears no
   relationship with the organization of source files on the OS.
   - packages automatically kick in whenever the module name has periods in
   it. Local renaming is explicit.
   - packages can support a hierarchy. Local renaming has no hierarchy at
   all.

I don't think one could necessarily kill the other, although it could render
it much less useful as a whole.

I would also not want to do the package system's trial, but I do believe
errors and abuses in the local renaming system are much simpler to solve and
handle than errors and abuses under the packages model. The reason is
simple: local renaming is local to a module, packages are global to every
module.

----
There are already a few potential problems that are easy to see in advance.
The first of these has to do with variables to carry module names around.
Let's reuse the robot example. The following is a legal call:

X = robot_brain,
X:analyze([a,t,f,e,b,s,c,z]).

However, if we say:

-rename(robot_brain, brain).
...
X = brain,
X:analyze([a,t,f,e,b,s,c,z]).

then the call should fail because 'brain' won't be expanded. This example is
trivial, but the issue is the same with module names coming from function
calls or messages. I don't know how packages handle this, maybe they do it
better.

Another issue is to avoid renaming modules that were already renamed. Not
because it's a technical problem, but rather because I believe we should
strive for simplicity rather than flexibility on that one. That is up for
discussion I guess.

Another potential weakness of the idea is that it only prevents one kind of
namespacing conflicts. In no way does it address ETS table names clashes,
registered processes clashes, etc. It might get confusing to use the
namespace for one but not the others.

So, what's your opinion? You might find the whole thing interesting or
totally worthless, but in either case I find this list's opinions worth
reading on this kind of issue.