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

[Nic Ferrier]

Stefan Monnier <address@hidden> writes:

>>> 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.
>
> No, a namespaced package can just as easily call `intern'.
> But even if you can hope the a namespaced package wouldn't do it, the
> non-namespaced packages are very numerous and do all kinds of nasty
> stuff and we have very little control over them (e.g. they're not
> bundled with Emacs).

If a namespace package calls intern the symbol is interned in the
private 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.
>
> That sounds like a very remote problem to me.  And if/when concurrency
> is added it doesn't seem like it should be difficult to make it
> work reliably.

Agreed.

>> My feeling is that an import should be like the creation of an alias.
>
> Function alias?  Variable alias?
> I don't much like the sounds of it.  I'd much rather make sure they are
> simply one and the same symbol (I guess "symbol alias").

Ok. Well I think I'm going to go through that in much more detail and
update the proposal.

>> 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.
>
> I'm not sure why the implementation should be difficult.  `intern' would
> "simply" need to parse the string into a list of elements (separated by
> "::" or whatever), then lookup the first element in the obarray, which
> should contain another obarray, then lookup the second element in that
> obarray, etc... until the last element which is handled "in the old
> way".

It would clearly be more work to add the extra indirection to allow
namespaced namespaces than to have one level.
 
But I'll spec it out more closely.


Nic