[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proper namespaces in Elisp

From: Andrea Corallo
Subject: Re: Proper namespaces in Elisp
Date: Tue, 05 May 2020 10:54:11 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Andrea Corallo <address@hidden> writes:

>> 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"))
> 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.

OTOH in elisp we would write:

(defun xxx-foo ()

and not

(defun xxx-foo ()

And this because we are smarter then the reader :)

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]