what's so difficult about namespace?

[Gene]

On Nov 26, 9:15 am, Xah Lee <xah... at gmail.com> wrote:
> On Nov 26, 5:45 am, Joshua Cranmer <Pidgeo... at verizon.invalid> wrote:
>
> > > i cannot fathom what could possibly be difficult of
> > > introducing or implementing a namespace mechanism into a language.
>
> > Namespaces go to the very core of a language, name resolution.
> > Retroactively adding such a feature is extremely difficult because there
> > is a strong chance of accidentally breaking existing code.
>
> could you give some technical detail on this?
>
> i don't know compiler so am probably being foolish here... but i
> suppose ultimately name resolution and storage at heart is something
> like a hashtable...  namely,
>
> put ‹identifier 1› table
> put ‹identifier 2› table
>
> and lookup is just
>
> retrieve ‹identifier› table
>
> and now suppose we introduced namespace, so i imagine the compiler
> simply just concat namespace component befor put, and split before
> retrieve?
>
>   Xah
> ∑http://xahlee.org/
>
> ☄

I'm sorry for the earlier post.  I read your question too quickly.

I've implemented a few research compilers; none in production.  You're
totally right in the case where the language has general nested
lexical scoping.  Namespaces just add an "outermost" scope.  If you've
done a good engineering job, the compiler change is trivial. In fact I
added namespaces like this to an assembler that had lexical scoping.
It took about an hour including writing a test suite.

If you already have a bunch of compilers for a language like pre-
namespace C or Javascript or Basic that doesn't allow for lexical
scoping, then the addition is likely to be non-trivial because the
implementation compiler language is often C and C programmers will
tend to declare a single, global symbol table.  So adding a separate
outer scope involves hunting down all the global references and
replacing them with references to the current namespace table.  We can
tut tut about this being bad design, but there you have it...