RE: adding namespaces to emacs-lisp (better elisp?)

[Drew Adams <drew.adams@oracle.com>]

> > * `import': Importing a symbol into a package.  Importing makes the
> > symbol *present*, not just *accessible* in the importing package.
> > If a different symbol with the same name is already accessible in the
> > importing package then a user-correctable error is raised: `import'
> > avoids letting one symbol shadow another.
> 
> Sounds like CL's approach requires symbols to be present in several
> packages, which might require more changes than I'd like in the way
> obarrays and symbols work.
> 
> AFAIK in Mathematica, the list of obarrays to search is just part of the
> current reader state, not a property of obarrays, whereas it seems that
> in CL the list of obarrays to search is stored in obarrays as a list of
> "parent" obarrays (so the list of obarrays to search is changed when we
> change the current obarray, whereas in Mathematica the two are unrelated).
> 
> I get the impression that Mathematica's design might be fairly easy to
> reproduce with the current Emacs code, whereas CL's design would
> probably require more changes.

Please do not judge only by my paraphase.  Please check CLTL2 yourself
before deciding.  A lot of thought - and years of practice - went into
the definition of the CL package system.  Wrt the consistency rules,
for example, CLTL says this:

"Package-related bugs can be very subtle and confusing: things are not
 what they appear to be.  The Common Lisp package system is designed
 with a number of safety features to prevent most of the common bugs
 that would otherwise occur in normal use.  This may seem over-protective,
 but experience with earlier package systems has shown that such safety
 features are needed."