[erlang-questions] Time to update programming rules?

[Edwin Fine]

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.

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.

The worse problem is the ability to have two modules with different names to
refer to the same module. That's a showstopper.

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).

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...

On Thu, Sep 4, 2008 at 11:14 PM, Richard A. O'Keefe <ok@REDACTED>wrote:

>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080905/272b9b2f/attachment.htm>