[erlang-questions] Package Support/Use

[Eric Merritt]

I am going to try to answer some of this.

On 11/1/06, Dominic Williams
<xpdoka-dated-1162835426.9cdf0e@REDACTED> wrote:
> Hi Eric,
>
> Sean pointed out:
>
> > It looks a bit like Java and is therefore not to the taste
> > of many hardcore Erlang hackers.
>
> Yes, but it's not just snobbery: I worked for years with C++
> namespaces and Java packages, and they have problems that I
> would not like to relive with Erlang.
>
> The current Erlang package system confuses several issues:
>
>  - avoiding module name clashes
>
>  - grouping related modules together logically
>    (semantically)
>
>  - grouping related modules together physically (file
>    system)
>
> NAME CLASHES
> ------------
>
> Using packages to avoid name clashes has two flaws:
>
> 1) it only reduces the likelyhood of a name clash, and if
>    one occurs nevertheless you are back to square one;

Very true. However, it does does a reasonably good job of reducing the
the likelihood. As we have seen so often in the past, many times a
'Good Enough' solution that is available now is better then a perfect
solution that might be available at some point in the (distant)
future.


> 2) it forces you to deal all the time with a problem that
>    may never occur, or rarely occurs.

True as well. However, packages have other benefits that reduce the
onerousness of this task.

> Both of these are because the problem is being dealt with at
> the wrong time. Name clashes should not be avoided before
> they occur, they should be resolved if and when they occur.

I would like to see an example of this that works when the name
clashes are between third party modules.

>
> SEMANTIC STRUCTURE
> ------------------
>
> There is something to be said for being able to use the same
> name in different contexts, being able to distinguish them
> when necessary but not bother when in a given context. For
> example, Graphic.Train (a graphical UI object) and
> Radio.Train (representing a radio connection with a train):
> it's nice to call them both Trains, and not to need to
> specify Radio all the time in the rest of the Radio code.
>
> This comes up a lot in object-oriented designs, but in
> Erlang, I am not so sure. Modules don't map to
> classes. Modules are already closer to what packages can be
> used for from a design perspective.


It has very little to do with classes and everything to do with
contexts. Erlang has just as much context as any other language. A
'worker_supervisor' in one application (or even one context) may be
doing a completely different thing then a 'worker_supervisor' in
another.

> In any case, the name clash avoidance situation comes and
> spoils this otherwise legitimate use of packages, because:
>
> 1) to further reduce the chance of clash, no one resists the
>    temptation of introducing additional levels (company
>    name, product, ...) which have NO value in terms of
>    describing the design and NEGATIVE value in terms of
>    making the code clearer.

True, however, this is  a sociological issue not a technical one. It
also depends very much on standards a community has set. We have the
power to set our one standards on what is the right and wrong way to
name packages.

>
> 2) because packages encourage you to think about this kind
>    of structure too soon, the package organisation is
>    usually too complex and often does not even map to the
>    code dependencies.


Very true, once again its a sociological problem rather then a
technical one. I don't actually have a solution here except to
encourage people to not do this.

I will say that bringing up problems these types of sociological
problems isn't very helpful. Saying that users will do this or users
will do that is just hand waving. User might do that and some users
probably will, but that doesn't imply that they can't be lead in the
right direction.

> PHYSICAL STRUCTURE
> ------------------
>
> Forcing the package structure to be mapped to a directory
> structure is a real pain.

I tend to agree with you here, but I am somewhat mixed on the issue.

> First, the directory structure becomes so much more
> complex. It's not only in the editor (I am not an Emacs
> newbie, and I use tags - although I haven't checked if they
> work with packages yet), it's also all the rest: things you
> do in the shell, scripts, makefiles, version management...
>
> Richard O'Keefe argued that it's even a mistake to force any
> mapping onto the filesystem (even module names):
>
> http://www.erlang.org/ml-archive/erlang-questions/200309/msg00044.html
>
> Ideally, I would like Erlang to have no files at all, like
> Smalltalk. In a sense, any kind of mapping seems contrary to
> this ideal. On the other hand, I suppose writing tools that
> hide the filesystem is easier if the tools can make strong
> assumptions about the organisation of files.


I have to disagree with you here. The filesystem is the lingua franca
of all developement releated tools. Editors, version control systems,
differs, etc all speak to each other via the filesystem. Once you
remove the filesystem you remove the ability to use all of these other
systems and you end up reimplenting poor copies of them your your
environments world. This is an old old argument that has been rehashed
over and over again in the various lists. Its not worth rehashing
here. Suffice it to say that modules are currently intrinsically tied
to the filesystem. This is unlikely to change anytime soon so
continuing the trend shouldn't be an issue.



> ALTERNATIVE SOLUTIONS
> ---------------------
>
> The simplest way to resolve name clashes after they occur is
> to rename one of the modules. Better support for automated
> refactoring would make this easy, and I guess that covers
> 99% of the name clash situations.

This works well only if you control the entire code base. If I pull
module A from one open source project and module B from another I
don't want to change anything in module A or B. Touching files in
either invalidates all the tests that may have been run and it gives
me a local version that I now have to maintain. Neither of these
things are acceptable.

>

[snip good arguments for an eiffelish approach]

There are any number of very large problems with this approach in
erlang. Registered proc names alone would make this difficult and Vlad
sites quite a few more issues in his response.

In any case, all of this is blue sky and would take a huge amount of
effort on the part of the implementors and change the semantics of the
language to some extent for the users. Given the resources Ericsson
devotes to Erlang this might have a chance of happening sometime in
the distant future. Packages are available now and the work. This is
the pragmatic approach that Erlang has always taken there isn't any
reason not to take this approach again.

> Even if a renaming mechanism is too difficult to implement,
> I don't think packages system in its current form is
> satisfactory and I vote for it not to be officially adopted.
>
> Regards,
>
> Dominic Williams
> http://www.dominicwilliams.net
>
> ----
>
>
>
>