Re: Proper namespaces in Elisp

[João Távora]

On Mon, May 4, 2020 at 8:20 PM Stefan Monnier <address@hidden> wrote:
> > I can't even imagine what a solution that _doesn't_ operate on the reader
> > looks like. Are you talking about form walking macros that walk the
> > forms and switch the short version of names into the long versions
> > and intern everything into the same obarray?  Hmmm.
>
> Something like it, yes.
>
> E.g. in `macroexpand` we'd change the symbol case so that when a symbol
> has the shape `s:bar` we treat it a bit as if we were looking
> at `(: s bar)` so we pass it to the `:` macro which might replace it
> with `(gethash s-obarray 'bar)` or with `string-bar` or ...

Curious, I could live without the ":", TBH.  If in a file where
local-namespaces is the alist (("^s-" . "modern-string-")), I'd just
like to have an implicit macro walk the tree, naively replacing atom's
names with the listed transformations, using replace-regexp-in-string,
then intern and return that. No special obarray.  In other words, one
would find both "s-bar" (since that had been read already) and
"modern-string-bar" in the obarray, but only "modern-string-bar" would
have any meaning attached.  Then one would type either version in the
source file.  The advantage is that we could compile all that code
that
relies on s.el with minimal (if any) changes and a proper
modern-string.el.

This is easier done at the reader level, I think (then no polluting
"s-bar" would be found in obarray).  But I think it would work in the
macroexpand phase too, I think.  Some vapourware to consider.  And if
this doesn't count as namespaces, we could call it a
"compiler-assisted
shorthand system", I don't care.

João Távora