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

[Nic Ferrier <nferrier@ferrier.me.uk>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[resolution]
>>> - 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.

I don't think this is a serious problem personally. But I'm also not
wedded to global-obarray-first.

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

Again, it only matters if it's a non-namespaced package that does it.

> 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 am not wedded to the proposal of using the global obarray first. The
rules for interning are slightly more complicated in that case:

- given a string X
- lookup X in the local obarray
- if it exists return the symbol
- else
-  lookup X in the global obarray
-  if it exists return the symbol
-  else
-    add the symbol to the local obarray

The only problem I see here is the possibility of problems with
concurrency. The whole operation above would have to be atomic and it
involves lookups in two separate data structures.

But since Emacs doesn't have concurrency yet and it would be a very bad
idea at this stage to add unfettered concurrency of the sort that would
cause a problem here (if there were a GIL-less threads implementation
for example) and the existing concurrency branch is tied to a GIL then I
really don't think that is actually a real problem we need to worry
about.

Although I bet that's what both Guido and Matz said when they were
designing the namespace bits of Python and Ruby.


[import]
>> 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?

I guess this needs more careful specification because that would not be
true of aliases.

My feeling is that an import should be like the creation of an alias.


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

It's not that I don't like it per-se. I just want this to be easy to
implement in the first instance. If the implementation gets more
difficult later I have no problem with that. But initial low cost is a
good thing.


Nic