Re: Proper namespaces in Elisp

[Andrea Corallo]

João Távora <address@hidden> writes:

> On Mon, May 4, 2020 at 10:59 PM Andrea Corallo <address@hidden> wrote:
>>
>> João Távora <address@hidden> writes:
>>
>> > On Mon, May 4, 2020 at 7:30 PM Helmut Eller <address@hidden> 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 <address@hidden> 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.
>
> Well, let's have "all its implications" then. Because you've done
> nothing more than describe in simplified fashion what it does,
> and that's not an argument to support the contention that
> "it is a bad idea".

Here is a first simple implication of namespace at read-time:

#+SRC_BEGIN lisp

(make-package :xxx)
(in-package :xxx)
(defun foo () 'aaa)
(export 'foo)

(make-package :yyy)
(in-package :yyy)
(use-package :xxx)

(if (not (eq (foo) 'aaa))
    (print "boom"))

#+END_BEGIN

This is because foo is not returnig 'aaa' but 'xxx::aaa'.

It will be told that you have to export also 'aaa' from the package xxx
because "leaking symbols" is bad.  But in reality this implies you have
to identify all execution paths that can leak a symbol and remember to
export these syms otherwise you'll get subtle bugs for any symbol leaked
passed in any kind of object.

Sure can be done (it is done) and we all got used to that but is just a
source of bugs due to bad design, not a feature.

One should import from a package *bindings* not symbols.  Unfortunatelly
the implementation can't distinguish those at read time because those do
not exists already.

With all the goodies of CL packages are really not the best example to
look at :)

>
>> 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 too think a dumb man's namespacing can be implemented,
> just to alleviate this alias-all-the-functions pressure.  Did you
> read my shorthand idea, I think it could fly.

I don't think the soulution should be dumb, and I think we should aim
for the correct solution if we decide to go for it.  IMO a good part
of the code is already present to support this but as usual the bring-up
would be considerably slower that the original optimistic expectation.

That said without a prototype all of this is just blablabla :)

Andrea

-- 
address@hidden