From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: new `obarray` type Date: Mon, 13 Mar 2017 22:03:35 +0000 Message-ID: <20170313220335.GA5098@acm> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1489442691 32015 195.159.176.226 (13 Mar 2017 22:04:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Mar 2017 22:04:51 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 13 23:04:46 2017 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 1cnY56-0007NH-Iz for ged-emacs-devel@m.gmane.org; Mon, 13 Mar 2017 23:04:44 +0100 Original-Received: from localhost ([::1]:54638 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnY5B-0003Y6-0L for ged-emacs-devel@m.gmane.org; Mon, 13 Mar 2017 18:04:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnY4c-0003Xo-3V for emacs-devel@gnu.org; Mon, 13 Mar 2017 18:04:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnY4Z-0006OC-00 for emacs-devel@gnu.org; Mon, 13 Mar 2017 18:04:14 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:17124 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cnY4Y-0006NI-M3 for emacs-devel@gnu.org; Mon, 13 Mar 2017 18:04:10 -0400 Original-Received: (qmail 22623 invoked by uid 3782); 13 Mar 2017 22:04:07 -0000 Original-Received: from acm.muc.de (p4FC46E3E.dip0.t-ipconnect.de [79.196.110.62]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Mar 2017 23:04:07 +0100 Original-Received: (qmail 5321 invoked by uid 1000); 13 Mar 2017 22:03:35 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 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:212999 Archived-At: Hello, Stefan. On Sun, Mar 12, 2017 at 21:36:26 -0400, Stefan Monnier wrote: > The patch below introduces a new type for obarrays, distinct > from vectors. Among other things, this makes it possible to print them > in a more useful way (it doesn't print the contents, only the size, so > the printed form is not computer-readable, but it's more > palatable to the user). It's not more palatable to this user. It sounds more like "dumbing down". There are few things more frustrating whilst debugging than having Emacs obfuscating information "for my own good". Indeed, why not just print _all_ vectors by printing only their size? The arguments which apply to obarrays surely apply equally to all vectors. Not rarely, particularly in CC Mode, I will be dealing with obarrays with relatively small numbers of symbols. Of course I want to see these symbols' names when I ask for that obarray to be printed. Being told its "size" would be utterly useless and infuriating. I suspect most obarrays in existence (with the essential exception of Emacs's main obarray) are relatively small, hence printing them as a vector is the Right Thing to do. I'm also not in favour of introducing another vector-like type without a very good reason. It feels a bit like XEmacs's introduction of a char type, distinct from the integer type. That was very clever, and no doubt pleased academic computer scientists, but I doubt it brought much benefit - it just created hassle, e.g. when looping through character positions. Would a new obarray type prevent any vector operations being carried out on it, should any package do such things? If so, that would be a Bad Thing. This change would create hassle in general for many packages, all of which create obarrays with (make-vector LENGTH 0), and would need changing to use `make-obarray'. It would mean having to write yet more compatibility macros (for the inevitable day when old style obarrays get removed from Emacs). This change would hinder debugging and development. All for what? > Printing obarrays in a `read`able way seems like something that should > be under the control of variable, since it's unclear in general what it > would mean (for abbrev-tables, it would probably mean to print the name > of every symbol, along with it value, function, and plist slots, but > doing that for the `obarray` variable doesn't seem right (and it's not > even clear what the `value` of each symbol in it should be, for > buffer-local symbols)). I'm against this change, at least at the moment. > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany).