<div dir="ltr">Thanks for repeating yourself. I didn't know you had posted about it before, and sometimes I don't even think of searching the lists, mea culpa.<br><br>I empathize with your pain at having to hack modules with namespace/directory changes. I have done this too many times (actually, once is too many times) with Java to develop a serious allergy to its namespace mechanism. Then again, if you are amenable to IDEs, Eclipse allows you to refactor Java quite painlessly, including moving between namespaces. Of course, that won't stop namespace changes from breaking someone else's existing code that uses the old namespace. I will look into C/Mesa and Lace - they sound interesting.<br>
<br>The worse problem is the ability to have two modules with different names to refer to the same module. That's a showstopper.<br><br>I am reminded of another namespace abomination, namely the addition of namespaces to XML. XML names were originally allowed to contain the colon character. This became a way to retrofit namespaces to XML without breaking backward compatibility (much).<br>
<br>It seems that much evil is done in many spheres to retain backward compatibility, especially in the face of temporal or market pressures - remember the segmented x86 architecture? I wonder how many people on this list were forced to work with the various x86 compiler memory models (IIRC, tiny, small, compact, medium, large, and huge). I was praying that the 68000 would win. Oh, the horror, the horror...<br>
<br><div class="gmail_quote">On Thu, Sep 4, 2008 at 11:14 PM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 5 Sep 2008, at 2:55 pm, Edwin Fine wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
Richard,<br>
<br>
Please will you clarify what you mean by<br>
<br></div><div class="Ih2E3d">
(a) we should not use them because they are inside out<br>
</div></blockquote>
<br>
I have discussed this at length in this mailing list.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do you mean, we should not use these facilities at all, ever, because the design is badly flawed,<br>
</blockquote>
<br></div>
Yes.<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
</blockquote>
<br>
One fundamental issue is that dotted names are just that:<br>
a *FLAT* module name space that just happens to allow dots<br>
in identifiers.  Since Erlang already allows @ signs in<br>
identifiers, if we had wanted to use names like<br>
    mnesia@CORBA@connector@impl<br>
we could have and can still.  (Think of the "@" signs as<br>
"fat dots".)  Allowing dots in identifiers doesn't, in<br>
principle, accomplish anything that allowing at-signs in<br>
identifiers doesn't.<br>
<br>
Well, there's some sort of abbreviation rule, but all that<br>
does is to mess things up horribly.  It is now possible for<br>
two *different* names to refer to the *same* module.  It is<br>
also possible for a module (with no mentions of its name<br>
anywhere other than ?MODULE) to break if you change its name.<br>
In fact, changing the name of a module that doesn't mention<br>
its name ANYWHERE other than the -module directive can break it.<br>
<br>
Why I say it's inside-out is that "compound names" for modules<br>
need to be relative to the starting module, not "absolute",<br>
so that you can move an entire cluster of related modules<br>
in a single renaming, WITHOUT having to hack on every single<br>
file.<br>
<br>
The design also perpetuates a great nastiness from Java, that<br>
of mixing up the dotting structure of module names with the<br>
arrangement of files in a file system.  I have just spent a<br>
painful half hour trying to read the documentation and sources<br>
for a Haskell package I'd like to use.  They've followed Java's<br>
lead with module names.  One result is that what seems to this<br>
potential user like *ONE* thing is actually broken up into<br>
about 30 pieces; instead of one coherent manual there are<br>
disconnected bits all over the place.  Instead of one directory<br>
with all the source files, there is a great tree with files,<br>
even files that are conceptually at the same level, not only<br>
in different directories but in directories at different levels.<br>
<br>
The right thing to do is to have a "configuration" language like<br>
C/Mesa or LACE.<br>
<br>
<br>
</blockquote></div><br></div>