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: Nic Ferrier
Subject: Re: adding namespaces to emacs-lisp (better elisp?)
Date: Fri, 26 Jul 2013 17:56:50 +0100

Stefan Monnier <address@hidden> writes:

>> We had a lot of discussion recently about making EmacsLisp
>
> I'm not sure I understand: do you mean Emacs does not Lisp enough yet?

Heh. Yeah. I dropped a word. I am going to work on blaming someone or
something for that and get back to you.

What I meant to say was:

  We had a lot of discussion recently about making EmacsLisp better.


> Comments:
> - "Interning a symbol with "::" in it should no longer be possible.
>   It should raise an error."  Why not simply intern it in the
>   corresponding namespace?  It's probably a bad practice, but Emacs is
>   usually not in the business of preventing bad practice.

That is a good idea. I will update the document with that. I agree emacs
is better off with it's laissez faire attitude.


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


>   Currently, we're very liberal about interning in the global obarray.
>   Basically I think this shadowing rule makes things a bit too
>   automatic for something where we need more control.

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.

*Eventually* I'd expect things like the face use-case to be dealt with
in some sort of namespace system.


> - I'm not sure exactly how you expect importing namespaces
>   should/will work.

I'll try and add some examples I guess. It's quite simple though, if I
have a package "nic" with 2 functions:

  foo
  bar

and you have a package "stefan", then you should be able to make aliases
to nic::foo and nic::bar in "stefan" namespace.

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

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.

I'm not sure about that last bit.


Nic



reply via email to

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