Re: new `obarray` type

[Alan Mackenzie <acm@muc.de>]

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