bug#7146: (make-symbol "") issues

[MON KEY <monkey@sandpframing.com>]

Chong Yidong wrote:

> I guess we could make intern and make-symbol signal errors for the empty
> string.

That would be great!

So, IIUC is the rationale for doing this is that there aren't really
any particularly
good reasons to intern the empty string given that the reader is incapable of
reading it correctly? If so, maybe, along similar (inverted) lines the forms:

 (make-symbol "nil")/(intern-soft "nil")(intern "nil")

should signal errors as well?

I.e as it's impossible to correctly re-intern (with read or otherwise) an
uninterned `nil' there should be no reason that one should need to
make-symbol/intern-soft/intern "nil" either?

Note however there is this:
bug#5672: 23.1; (intern-soft "") returns non-nil
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-03/msg00026.html')

Which may not comport with your decision to have
`intern'/`make-symbol' signal error.
In bug#5672 Stefan states that interning the empty string is not a bug
because it might not always be done purposefully (IIUC).

But note there is this more recent discussion:

Date: 	Sat, 11 Sep 2010 19:33:07 -0400
Subject: Save `nil' from the mutant void, preserve the truth of
	 falsehood, prevent the falsehood of truth
(URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00464.html')

Where it is pointed out that `intern-soft'ing the emtpy string with e.g.:

 (prog1 #1=(intern-soft "") (unintern #1#))

is potentially problematic (at either compile or runtime).

Note that the new `unintern' semantics requiring provision of an
`obarray' account
for some part of the problem. (This said, IMHO I still consider the form above a
source of myriad potential security holes and abuse, new obarray
semantics or no.)

Whatever, b/c is difficult to prove formally that these potentialities for abuse
exist without dialogue them publicly and b/c doing so is currently an
exercise in self-flagellation given the absence of a willingness for honest
public examination of the shortcomings of the Elisp reader the best one can do
is hint at their possible implementation and home someone "gets it"...

From from the same thread:
(URL `http://lists.gnu.org/archive/html/emacs-devel/2010-09/msg00494.html')

There is also this example (relevant to the current bug) which provides an
illustration of the vagaries of `intern-soft' w/re the empty string.

The more salient portion included below for completeness:

,----
|
| > since `intern' only takes a string rather than a symbol.
|
| Yeah, but again there is the weird corner case of interning the 0
| length string.  Which, as shown in previous mail causes additional
| headaches when attempting to re-intern a symbol.
|
|
| emacs -Q
|
| (prin1
| (let ((s1 (intern (symbol-name (make-symbol ""))))
|      (s2 (intern (symbol-name '#:)))
|      cmp)
|  (setq cmp `((,#1=s1 ,#1#) (,#2=s2 ,#2#)))
|  `(:S1-LEN ,(length (car cmp))
|    :S1-LEN ,(length (cadr cmp))
|    :S1-IS-S1 ,(eq (caar cmp) (car (cdar cmp)))
|    :S2-IS-S2 ,(eq (car (cadr cmp)) (cadr (cadr cmp)))
|    :CAR-S1-IS-CAR-S2 ,(eq (caar cmp) (car (cadr cmp)))
|    :CADR-S1-IS-CADR-S2 ,(eq (car (cdar cmp)) (cadr (cadr cmp)))
|    :S1-IDENTITY ,(identity s1)
|    :S1-IDENTITY ,(identity s1)
|    :S1-SYM-NAME ,(symbol-name s1)
|    :S2-SYM-NAME ,(symbol-name s2)
|    :S2-UNINTD   ,(unintern (car (cadr cmp)))
|    :S1-UNINTD   ,(unintern (caar cmp))))
| (current-buffer))
|
| (:S1-LEN 2 :S1-LEN 2
|  :S1-IS-S1 t :S2-IS-S2 t
|  :CAR-S1-IS-CAR-S2 t :CADR-S1-IS-CADR-S2 t
|  :S1-IDENTITY  :S1-IDENTITY  ;; <- Note, that _is_ an identity
|  :S1-SYM-NAME "" :S2-SYM-NAME ""
|  :S2-UNINTD t :S1-UNINTD nil)
|
`----

Maybe too, `make-symbol' and `intern' should also have mandatory
obarray arguments in keeping with the new semantics for `unintern'?

--
/s_P\