Re: Proper namespaces in Elisp

[Andrea Corallo <akrl@sdf.org>]

João Távora <joaotavora@gmail.com> writes:

> On Mon, May 4, 2020 at 7:30 PM Helmut Eller <eller.helmut@gmail.com> wrote:
>> should be done by the compiler (like lexical scoping).  In other words,
>> those people would like a mechanism to manage the names of variable
>> bindings not a mechanism to manage symbols.
>
> That last sentence sounds clever but I can't fully grok it. Do you
> really mean "variable bindings" or just "bindings"? (including function's).
>
> On Mon, May 4, 2020 at 7:39 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Richard mentioned his profound dislike of solutions that operate in
>> the reader.  I'm not sufficiently familiar with Common Lisp's package
>> system to have a strong opinion on that, but Richard's criticism does
>> appeal to me (I've been brought up on namespace systems more like
>> Standard ML's structures).
>
> 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.

Namespaces in the read time is a bad idea because it does not affect
only bindings but effectively all symbols.  I, as many others, do not
like CL package system too for this reason and all its implications.

For having a namespace system that works only on bindings a new
indirection must be added.  That implies that implementation-wise you
cannot keep the symbol-value directly in the symbol.  In this way you
can have more consumers of the same binding (that is what happend when
you import from another namespace).

One could argue that this will cause a slow down in code execution but
this is non true given this indirection has to be solved in the
compile-time for compiled or byte-compiled code.

Effectively namespace resolution is then moved from the read-time to the
compile-time.  And with that you solve also the problem of the code
walker because the compiler it is already *the* code walker.

I think Emacs has most of the infrastructure to implement this already
in the codebase but right now I've not time to work on a prototype (I'm
not sure either how much this feature is really desired).

  Andrea

--
akrl@sdf.org