From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: server-local variables Date: Mon, 31 Oct 2016 22:08:43 -0700 (PDT) Message-ID: References: <87r36x7kb9.fsf@gmx.de> <87wpgoofp3.fsf@lifelogs.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1477976998 26850 195.159.176.226 (1 Nov 2016 05:09:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Nov 2016 05:09:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 01 06:09:54 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c1RKH-0003hn-28 for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 06:09:33 +0100 Original-Received: from localhost ([::1]:39858 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1RKI-000683-Kx for ged-emacs-devel@m.gmane.org; Tue, 01 Nov 2016 01:09:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1RJi-00067k-3c for emacs-devel@gnu.org; Tue, 01 Nov 2016 01:08:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1RJd-0002bi-5K for emacs-devel@gnu.org; Tue, 01 Nov 2016 01:08:58 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:25104) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1RJc-0002a9-TF for emacs-devel@gnu.org; Tue, 01 Nov 2016 01:08:53 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uA158o6x028757 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 1 Nov 2016 05:08:51 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id uA158nml011015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Nov 2016 05:08:49 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uA158jgp029248; Tue, 1 Nov 2016 05:08:47 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209054 Archived-At: > > I use an obarray in `synonyms.el', for example, for the > > names in a dictionary (thesaurus). > > (https://www.emacswiki.org/emacs/Synonyms) >=20 > That's exactly an example where you use obarrays to do > something similar to modules. Oh, that's what you meant by "modules"? Had you mentioned "namespaces" (or even just separate sets of "symbols", or even "something similar to Common Lisp packages"), that might have been clearer. (Especially in light of the recent discussions of adding a different sort of "modules" to Emacs.) See Ted's reply, where it seems he thought of an obarray for exactly the reasons you and I apparently agree that obarrays _can_ be appropriate: to wall off sets of symbols: > OK, it seemed like you were basically designing a scoped > symbol table per connection, so an obarray seemed sensible. > I haven't worked with them so it was just a question for > my education. But if they are actively discouraged for > most usage, the ELisp manual section on Creating Symbols > should mention that. I was not aware. He seems to have taken your admonition somewhat similarly to how I did. Had you just said that you don't think separate symbol namespaces are needed here, I don't think there would have been any confusion. It was not clear, to me at least, why you said that obarray use cases are *very* rare.=20 And if it _is_ needed here to have separate sets of symbols (some of which could have the same name), then "Why not an obarray?" isn't an unreasonable question. Perhaps your reply was just your way of asking "Do we need separate sets of symbols here?", or your way of saying that we do not?