Re: Proper namespaces in Elisp

[Tuấn-Anh Nguyễn]

On Fri, May 8, 2020 at 3:29 AM Stefan Monnier <address@hidden> wrote:
>
> > I don't like reader magic. It complicates code logic. I know we talked about
> > symbol-macrolet and macrolet as possible options and know why neither is
> > quite the right thing, but I still think that a macro of the same general
> > kind would work fine. Macros don't need to recognize defining forms if they
> > macroexpand their bodies before walking them.
>
> You need not only discover the defining forms but also the "using"
> forms.  So you need to know that the arguments to `make-local-variable`,
> `add-hook`, `symbol-value`, `facep`, ... (and all function that pass
> their arg to one of those) are not just random symbols (that you should
> leave untouched) but symbols that obey the namespace rules.
>

Alternatively, the design could be:

1. Each symbol’s associated namespace is a first-class concept. So is
   the fact whether a symbol is fully qualified.
2. Each namespace is itself a first-class construct, which holds
   information about symbols imported directly from other namespaces
   (used), and desired aliases of other namespaces.
3. Resolving an unqualified symbol into a qualified one is done by
   consulting a “current namespace” context, and is likewise a first-class
   operation available not just to the reader.
4. The reader returns qualified symbols only when explicitly asked
   (through a "reserved namespace separator"), or configured (i.e.
   imported symbols). It normalizes locally-defined namespace aliases
   while doing so.
5. Primitives that deal with symbols directly become namespace-aware.
   They resolve unqualified symbols when encountering them, using the
   mechanism in 3. These include `set`, `defalias`,
   `make-local-variable`, `funcall`, `symbol-value`, ...

--
Tuấn-Anh Nguyễn
Software Engineer