emacs-devel
[Top][All Lists]
Advanced

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

Re: adding namespaces to emacs-lisp (better elisp?)


From: Stefan Monnier
Subject: Re: adding namespaces to emacs-lisp (better elisp?)
Date: Fri, 26 Jul 2013 14:18:48 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>> - I'm not sure how well it will cope with shadowing and non-namespaced
>> symbols (e.g. symbols like `face' that aren't used as variables).
>> The rule "global obarray is inspected first and if a symbol is found
>> there that's what is used" means that we have to be vary careful about
>> interning things in the global obarray since it can affect the way
>> other code is handled.
> Give an example of a potential problem?
> I *think* you mean that adding new global symbols could affect
> namespaced code. But I don't think that's any different than right now.

Here's a scenario:
- namespaced packages A and B both locally define a function `toto'.
- non-namespaced package C comes along with a symbol `toto' somewhere in
  its code, suddenly causing A and B's `toto' to be global rather
  than local.

Note that instead of "non-namespaced package C", we could have some
package which uses symbols as "uniquified strings" and which uses the
global obarray for it and might occasionally intern `toto' in the course
of its normal execution.

IOW I think we should instead first look in the local obarray (over
which the coder does have control) and if that fails then look in the
global obarray.

> I disagree that's a reason not to try it. Yes, it could be a
> problem... but the presumption has to be that new code would use this
> way to namespace itself and that global pollution would therefore slow
> down.

Old non-namespaced, hideous, dynamically scoped is Emacs's bread and
butter and we can't hope for it to disappear soon.

> Ideally that should work with some simple statement:
>  ;; Package: stefan
>  (import 'nic)
>  (foo)
> in this example nic::foo and nic::bar would both be imported directly
> into "stefan" and after that was done the following would be true:
>   (eq (symbol-function 'nic::foo)
>       (symbol-function 'stefan::foo))

Should this equality still stand if I (fset 'nic::foo 'blabla)?
I.e. is it one and the same symbol?

> or:
>  (import 'nic :as 'blah)
>  (blah::foo)
> in this example nic::foo and nic::bar would be imported under the
> namespace 'blah in the package "stefan".
> I guess this could then be a use case for trees of namespaces, so that:
>  (stefan::blah::foo)
> was possible.

Indeed, my impression is that you inevitably get to this kind
of situation, which you seemed to dislike.  I personally don't find it
problematic, not even if we generalize it to some arbitrary graph, with
cycles and all.


        Stefan



reply via email to

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