From: Nic Ferrier <nferrier@ferrier.me.uk>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: adding namespaces to emacs-lisp (better elisp?)
Date: Fri, 26 Jul 2013 22:43:25 +0100 [thread overview]
Message-ID: <87mwp90zgi.fsf@ferrier.me.uk> (raw)
In-Reply-To: <jwv38r1jbhm.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 26 Jul 2013 16:59:58 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> 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
next prev parent reply other threads:[~2013-07-26 21:43 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 14:08 adding namespaces to emacs-lisp (better elisp?) Nic Ferrier
2013-07-26 14:34 ` Drew Adams
2013-07-26 17:01 ` Pascal J. Bourguignon
2013-07-26 17:01 ` CommonLisp namespace system (was Re: adding namespaces to emacs-lisp (better elisp?)) Nic Ferrier
2013-07-26 17:19 ` Drew Adams
2013-07-26 18:26 ` Sebastian Wiesner
2013-07-26 18:53 ` Drew Adams
2013-07-26 21:08 ` Pascal J. Bourguignon
2013-07-26 18:23 ` Stefan Monnier
2013-07-26 18:32 ` Nic Ferrier
2013-07-26 18:45 ` Tom Tromey
2013-07-26 18:58 ` Drew Adams
2013-07-26 19:06 ` Nic Ferrier
2013-07-26 20:46 ` CommonLisp namespace system Lars Brinkhoff
2013-07-26 20:57 ` Drew Adams
2013-07-26 21:47 ` Nic Ferrier
2013-07-29 17:31 ` Lars Brinkhoff
2013-07-26 20:57 ` CommonLisp namespace system (was Re: adding namespaces to emacs-lisp (better elisp?)) Drew Adams
2013-07-27 7:17 ` Richard Stallman
2013-07-27 8:13 ` Nic Ferrier
2013-07-27 11:43 ` Bastien
2013-07-27 12:00 ` David Engster
2013-07-27 16:56 ` Nic Ferrier
2013-07-27 23:52 ` Richard Stallman
2013-07-28 7:22 ` Nic Ferrier
2013-07-28 8:18 ` Jambunathan K
2013-07-28 12:10 ` Richard Stallman
2013-07-28 13:48 ` Nic Ferrier
2013-07-29 10:12 ` Richard Stallman
2013-07-29 10:45 ` Nic Ferrier
2013-07-30 0:31 ` Richard Stallman
2013-07-27 9:37 ` CommonLisp namespace system Lars Brinkhoff
2013-07-26 19:42 ` CommonLisp namespace system (was Re: adding namespaces to emacs-lisp (better elisp?)) Drew Adams
2013-07-26 21:26 ` Juanma Barranquero
2013-07-26 21:06 ` Pascal J. Bourguignon
2013-07-26 21:44 ` Nic Ferrier
2013-07-27 7:16 ` adding namespaces to emacs-lisp (better elisp?) Richard Stallman
2013-07-26 15:43 ` Stefan Monnier
2013-07-26 16:56 ` Nic Ferrier
2013-07-26 18:18 ` Stefan Monnier
2013-07-26 19:00 ` Nic Ferrier
2013-07-26 20:59 ` Stefan Monnier
2013-07-26 21:43 ` Nic Ferrier [this message]
2013-07-26 21:59 ` Drew Adams
2013-07-26 22:21 ` Stefan Monnier
2013-07-26 22:33 ` Nic Ferrier
2013-07-27 0:51 ` Stefan Monnier
2013-07-27 8:27 ` Nic Ferrier
2013-07-27 14:12 ` Stefan Monnier
2013-07-27 16:17 ` Nic Ferrier
2013-07-27 17:28 ` Stefan Monnier
2013-07-27 10:35 ` Pascal J. Bourguignon
2013-07-26 22:00 ` Drew Adams
2013-07-27 0:49 ` Stefan Monnier
2013-07-27 1:13 ` Drew Adams
2013-07-27 7:02 ` Lars Brinkhoff
2013-07-27 10:33 ` Pascal J. Bourguignon
2013-07-31 6:48 ` Lars Brinkhoff
2013-07-27 10:31 ` Pascal J. Bourguignon
2013-07-27 14:14 ` Stefan Monnier
2013-07-27 16:43 ` Drew Adams
2013-07-26 17:21 ` Davis Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mwp90zgi.fsf@ferrier.me.uk \
--to=nferrier@ferrier.me.uk \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).