[erlang-questions] Time to update programming rules?

[Richard A. O'Keefe]

On 5 Sep 2008, at 2:55 pm, Edwin Fine wrote:

> Richard,
>
> Please will you clarify what you mean by
>
> (a) we should not use them because they are inside out

I have discussed this at length in this mailing list.

> Do you mean, we should not use these facilities at all, ever,  
> because the design is badly flawed,

Yes.
>

One fundamental issue is that dotted names are just that:
a *FLAT* module name space that just happens to allow dots
in identifiers.  Since Erlang already allows @ signs in
identifiers, if we had wanted to use names like
     mnesia@REDACTED@connector@REDACTED
we could have and can still.  (Think of the "@" signs as
"fat dots".)  Allowing dots in identifiers doesn't, in
principle, accomplish anything that allowing at-signs in
identifiers doesn't.

Well, there's some sort of abbreviation rule, but all that
does is to mess things up horribly.  It is now possible for
two *different* names to refer to the *same* module.  It is
also possible for a module (with no mentions of its name
anywhere other than ?MODULE) to break if you change its name.
In fact, changing the name of a module that doesn't mention
its name ANYWHERE other than the -module directive can break it.

Why I say it's inside-out is that "compound names" for modules
need to be relative to the starting module, not "absolute",
so that you can move an entire cluster of related modules
in a single renaming, WITHOUT having to hack on every single
file.

The design also perpetuates a great nastiness from Java, that
of mixing up the dotting structure of module names with the
arrangement of files in a file system.  I have just spent a
painful half hour trying to read the documentation and sources
for a Haskell package I'd like to use.  They've followed Java's
lead with module names.  One result is that what seems to this
potential user like *ONE* thing is actually broken up into
about 30 pieces; instead of one coherent manual there are
disconnected bits all over the place.  Instead of one directory
with all the source files, there is a great tree with files,
even files that are conceptually at the same level, not only
in different directories but in directories at different levels.

The right thing to do is to have a "configuration" language like
C/Mesa or LACE.