Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[MON KEY]

Two one-liners not even a Perl devotee could love:

(prog1 #1=(fboundp ()) (unintern #1#))

(prog1 #1=(intern-soft "") (unintern #1#))  ;; <- for the truly perverse

Approx. once per 1.5 weeks I find myself with a broken inadvertently uninterned
`nil' which leaves me with a semi-wedged Emacs session (usually this is a
singular session up since the last Emacs-crash/power-glitch).

Sometimes, I'm able to recover `nil' long enough to save the session, but even
then i've not any reasonable surety that the busted `nil' is a correct `nil'.

Other times a corrupted `nil' can so immediately frustrate Emacs' state that the
only safe solution is to put the old gal down ASAP.

Sans defadvice chicanery is there no explicit way to prevent
uninternment of the real `nil'?

emacs -Q

(sxhash nil)
;=> 19028

(intern-soft "nil")
;=> nil

(car nil)
;=> nil

(identity nil)
;=> nil

(fboundp 'nil)
;=> nil

(fboundp nil)
;=> nil

(fset 'nil  #'(lambda () (+1 1)))
;=> Debugger entered--Lisp error: (setting-constant nil)

(symbol-function 'nil)
;=> Debugger entered--Lisp error: (void-function nil)

(symbol-function nil)
;=> Debugger entered--Lisp error: (void-function nil)

(setq nil 'bubba)
;=> Debugger entered--Lisp error: (setting-constant nil)

(set 'nil 'bubba)
;=> Debugger entered--Lisp error: (setting-constant nil)

(unintern nil)
;=> t

(fboundp nil)
;=> Debugger entered--Lisp error: (void-variable nil)

(identity nil)
;=> Debugger entered--Lisp error: (void-variable nil)

(setq nil 'bubba)
;=> bubba

(identity nil)
;=> bubba

(car nil)
;=> Debugger entered--Lisp error: (wrong-type-argument listp bubba)

(fset 'nil  #'(lambda () nil))
;=> (lambda nil nil)

(symbol-function 'nil)
;=> (lambda nil nil)

(funcall 'nil)
;=> bubba

(funcall nil)
;=> Debugger entered--Lisp error: (void-function bubba)

(setq bubba nil)
;=> bubba

bubba
;=> bubba

(fset 'bubba #'(lambda ()))
;=> (lambda nil)

(funcall nil)
;=> nil

nil
;=> bubba

(setq nil (funcall nil))
;=> nil

nil
;=> nil

(symbol-value nil)
;=> nil

(set 'nil 'nil)
;=> nil

(sxhash nil)
;=> 19028

`sxhash' is all we've got... If I'm lucky the new `nil' is approximately
equivalent to the old `nil'.

Still, `sxhash' or no, the new `nil' is still extremely broken. To see
why see illustration below using `push' to turn `nil' into a list.

Apparently the uninternment of `nil' is not considered a "silly"
problem, e.g.  this comment in lread.c:

  /* There are plenty of other symbols which will screw up the Emacs
     session if we unintern them, as well as even more ways to use
     `setq' or `fset' or whatnot to make the Emacs session
     unusable.  Let's not go down this silly road.  --Stef  */

  /* if (EQ (tem, Qnil) || EQ (tem, Qt))
       error ("Attempt to unintern t or nil"); */

"Silliness" aside, I can't see how the above assertion is in
accordance with the manual.

,---- (info "(elisp)Standard Errors")
|
| `setting-constant'
|      `"Attempt to set a constant symbol"'
|      The values of the symbols `nil' and `t', and any symbols that
|      start with `:', may not be changed.
|      *Note Variables that Never Change: Constant Variables.
|
`----

"Never" is a long time and "may not be changed" sounds like a _promise_.

,---- (info "(elisp)Constant Variables")
|
| In Emacs Lisp, certain symbols normally evaluate to themselves.  These
| include `nil' and `t', as well as any symbol whose name starts with `:'
| (these are called "keywords").  These symbols cannot be rebound, nor
| can their values be changed.  Any attempt to set or bind `nil' or `t'
| signals a `setting-constant' error.  The same is true for a keyword (a
| symbol whose name starts with `:'), if it is interned in the standard
| obarray, except that setting such a symbol to itself is not an error.
|
`----

Apparently no one has bothered to tell the manual about `unintern'!

Or, maybe the manual _assumes_ that since other Lisp2's (e.g. Common
Lisp and forebears) thought it so it mus bet, and therefor didn't feel it
necessary to double check if this was kosher with the trash collector...

Indeed, it should be noted that CL implementations including CLISP, SBCL,
and CMUCL prevent (or otherwise make it very difficult) to unitern the
constants `t' and `nil'.

Yeah, I know, despite the Lisp-2'edness Emacs Lisp isn't CL...

So, how do the Schemes handle this? Is it possible to define/set away #f?

R5RS info says:
,----
| ,---- (info "(r5rs)Other notations")
| |
| | `#t' and `#f'.
| |  These are the boolean constants (section *note Booleans::).
| |
| `----
| ,---- (info "(r5rs)Literal expressions")
| |
| | As noted in section *note Storage model::, it is an error to alter
| | a constant (i.e. the value of a literal expression) using a
| | mutation procedure like `set-car!' or `string-set!'.
| |
| `----
`----

This said, Guile 1.9.10 doesn't seem to mind me let-binding `nil':

scheme@(guile-user)> (let ((nil 'bubba)) nil)
;=> bubba

Maybe this is because of some fundamental Lisp2 vs. Lisp1 tension around:
 (#t . t) (#f .  ) (nil . ())

Andy Wingo peered in on this recently:
(URL `http://lists.gnu.org/archive/html/guile-devel/2010-03/msg00077.html')

Still, Guile isn't nearly so promiscuous as to allow me equivocation with
impunity:

scheme@(guile-user)> (let ((#f #t)) #f)
;=> error
Good girl! Presumably other Scheme's are similar?

That Emacs lisp _pretends_ to not look kindly on a let-binding of
`nil' is even _worse_ than actually allowing me to do it:

(let ((nil 'bubba)) nil)
;=>  Debugger entered--Lisp error: (setting-constant nil)
Damn you Emacs lisp, when you lie to me I feel so cheap and used!

The error is in error, `nil' isn't a constant (not an immutable one anyhow).

Whatever, I understand that there are some GC issues w/regards marking
`nil' _truly_ special, but I simply can not understand how these
justify allowing uninternment of `nil'. Moreover the rationale for not
preventing it doesn't seem to jive with the fact that other Lisp
implementations of other Lisp dialects both Lisp1's and Lisp2's are
capable of preventing (and/or seriously restricting) the mutability of
falsehoods `nil', an `#f'.

By protecting the GC to the detriment of `nil' a nasty burden is
shifted onto the user which may cause her to doubt the truth of Emacs'
falsehood.

 "Nah, you can't trust ole Emacs... Gals trashy, and don't know how to
  tell the truth from da lies."

emacs -Q

(progn
  (unintern nil)
  (unintern 'nil))
;=>nil

nil
;=> Wrong type argument listp, nil

(set 'nil 'nil)
;=> nil

nil
;=> nil

(car nil)
;=> Wrong type argument listp, nil

(set 'nil ())
;=> nil

nil
;=> nil

(car nil)
;=> nil

(push '8 nil)
;=> (8)

nil
;=> (8)

Theres also this:

emacs -Q

(symbol-value (intern ""))
;=> Debugger entered--Lisp error: (void-variable )

(symbol-value nil)
;=> nil

(unintern nil)
;=> t

(set 'nil  (intern ""))

(identity nil)
;=>

Note, above thats not void its _nothing_ i.e. no return value!

As following illustrates:

(symbol-value nil)
;=> Debugger entered--Lisp error: (void-variable )

(let ((mv (make-vector 1 0)))
  (intern "" mv)
  (aref mv 0))
;=>

(unintern nil)

(set 'nil ())
;=> nil

(push 8 nil)
;=> nil

(unintern nil)
;=> Debugger entered--Lisp error: (wrong-type-argument stringp (8))

Most likely my arm waving won't avail to much and will fall on deaf
ears. Far more assertive arm waivers than I have failed to make the
case that saving `nil' is a worthwhile goal:

:SEE (URL `http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00298.html')

,---- RMS Sat, 14 Nov 2009 06:23:09 -0500
|
| As for their next pointers, if they are the first symbols to be
| interned, they are at the end of their obarray buckets, so their
| next pointers never need to be changed.  (We should make `unintern'
| check for t and nil and give an error.)
|
`----

,---- RMS Tue, 17 Nov 2009 02:57:08 -0500
|
|     I am skeptical that we have everything in place that is required
|     to properly support
|
|     (unintern nil)
|     (unintern t)
|
| We should make them give errors -- that's much easier than
| making them "work".  There's no reason they should be allowed
|
`----

,---- RMS Wed, 18 Nov 2009 07:11:39 -0500
|
| I will spend the time to make unintern give an error for t and nil.
|
`----

,---- RMS Thu, 19 Nov 2009 11:23:27 -0500
|
|     There are *many* ways for the user to shoot herself in the foot
|     and make her Emacs session completely unusable.
|
| We won't try all, but it is useful to catch some.  unintern is not
| used a lot, so don't worry about the cpu time.
|
`----

,---- CYD Fri, 20 Nov 2009 00:47:18 -0500
|
| (I sent an earlier email about this, but it seems to have gotten
|  lost.)
|
| FWIW, in CLISP and CMUCL (unintern nil) and (unintern t) are no-ops
| returning nil.  Presumably the other CL implementations do likewise.
|
| It seems to me that it'd do no harm to do likewise, but since others
| care strongly about this and I don't, I'll just shrug and go along...
|
`----

,---- Sam Steingold Sun, 22 Nov 2009 01:48:45 -0500
|
| i.e., it IS possible to remove the T symbol (with all the trouble this
| entails).
|
| As a CLISP maintainer, I don't think T & NIL are special enough.
| We lock entire packages.
| Please see <http://clisp.cons.org/impnotes/pack-lock.html>.
|
`----

,---- Dan Nicolaescu Thu, 19 Nov 2009 13:05:43 -0800 (PST)
|
| But not being able to unintern t and nil is not useful to anyone.
|
`----

,----  RMS Sat, 14 Nov 2009 06:23:16 -0500
|
| Sure, but even if it is only a small improvement for each person, it
| is still worth doing if it is easy.  Suppose that this small speedup
| transforms "annoying" into "not annoying" for just one user in a
| thousand each day.  That would mean that, each day, hundreds or
| thousands of people are happier.
|
`----

,---- RMS Sun, 15 Nov 2009 17:38:25 -0500
|
| Once in a while, this small speedup will be enough to make that
| difference for a particular person.  With so many users, it adds up.
| Also, several such small speedups do add up.
|
`----

Damn the speedup. The real cost savings is in not having to kill (and
recover from) a wedged/compromised Emacs session.

Whatever... Le roi est mort vive le éboueur!

--
/s_P\

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[Lars Magne Ingebrigtsen]

MON KEY <monkey@sandpframing.com> writes:

> Approx. once per 1.5 weeks I find myself with a broken inadvertently
> uninterned `nil'

How?

I think this sounds like a classic case of "don't do that, then".

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[Andy Wingo]

Hello,

On Sun 12 Sep 2010 01:33, MON KEY <monkey@sandpframing.com> writes:

> So, how do the Schemes handle this? Is it possible to define/set away
> #f?

In Scheme, #f and '() are not identifiers (symbols), so it is impossible
to set!  them.

> This said, Guile 1.9.10 doesn't seem to mind me let-binding `nil':
>
> scheme@(guile-user)> (let ((nil 'bubba)) nil)
> ;=> bubba

Nil does not exist in Scheme, so it is not bound. However Guile does
provide a separate nil value, which may be read as "#nil" -- again, not
an identifier.

(There is also a %nil symbol bound to #nil in the default environment
with deprecated symbols enabled, but that is a relic.)

There are still some nil-is-a-symbol-in-elisp issues to work out in
Guile. In fact there are still a number of symbols-are-fat-in-elisp,
symbols-are-just-immutable-strings-in-scheme issues to work out...

I don't think my comments have much bearing on your original comment,
though :)

Andy
-- 
http://wingolog.org/

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[Stefan Monnier]

> Two one-liners not even a Perl devotee could love:
> (prog1 #1=(fboundp ()) (unintern #1#))

Let's see how many lines of defenses you broke in the above code:
- use of #1= in code: very bad.
- unintern takes a symbol as argument, not a boolean, so it should not
  be called with the return value of (fboundp ...)
- calling unintern without an obarray arg is a bad idea.

Maybe we should make the second argument mandatory.

> Sometimes, I'm able to recover `nil' long enough to save the session,
> but even then i've not any reasonable surety that the busted `nil' is
> a correct `nil'.

The real nil is safely stored in a C variable `Qnil' which you should be
able to get via something like (not t).  But I don't think Elisp lets
you re-intern it, since `intern' only takes a string rather than a symbol.


        Stefan

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[MON KEY]

On Sun, Sep 12, 2010 at 10:00 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Two one-liners not even a Perl devotee could love:
>> (prog1 #1=(fboundp ()) (unintern #1#))
>
> Let's see how many lines of defenses you broke in the above code:

So what?

These opening two examples were intentionally pathological (and
relatively harmless) There are certainly more prosaic
examples. Likewise, there a others that are far more destructive than
those provided.  Would you prefer I provide those in a public forum as
well?

> - use of #1= in code: very bad.
Which code?

`#1=', and related reader syntax constructs aren't bad.

Indeed, they are quite prevalent in byte-code files and the language
would be hamstrung without them.

That there are any number of ways to (ab)use them is a case for
restricting the uninternment of two critical Lisp constants `t' and
`nil' (and especially nil).

> - unintern takes a symbol as argument, not a boolean, so it should
>   not be called with the return value of (fboundp ...)

No, the argument to `unintern' can be a symbol or string.

(progn
  (eval (read
         (concat
          '(40 100 101 102 97 108 105 97 115 32 39 98 121 101 32
            40 105 110 100 105 114 101 99 116 45 102 117 110 99 116
            105 111 110 32 40 98 121 116 101 45 99 111 109 112 105
            108 101 32 35 39 40 108 97 109 98 100 97 32 40 120 41 32
            40 117 110 105 110 116 101 114 110 32 120 41 41 41 41 41)
          nil)))
  (bye (symbol-name 'bye))
  (fboundp 'bye))


> - calling unintern without an obarray arg is a bad idea.
Yeah,
a) Because there is really only one first class obarray.
b) because restriction aren't placed on certain constants in obarray.

>
> Maybe we should make the second argument mandatory.

That would be nice.

But, it should also require that the NAME arg _must_ be a string.
Better yet would be to also return the string on success:

This would allow interrogation of the obaray with success on failure:

 (not (intern-soft (unintern "bubba33" '<mandatory-ob>)))
 ;=> t

>
> The real nil is safely stored in a C variable `Qnil' which you should be
> able to get via something like (not t).

`nil' has to evaluate for both the empty list and a "symbol constant".
`(not t)' just makes it a "symbol constant".

See illustrations from previous example w/re to push.

> But I don't think Elisp lets you re-intern it,

I can't find a way.

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

>
>        Stefan
>

/s_P\

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[Stefan Monnier]

> `#1=', and related reader syntax constructs aren't bad.

In source code, they are.  In source code, you have other ways to
express sharing, such as `let', which are much preferred.

> Indeed, they are quite prevalent in byte-code files and the language
> would be hamstrung without them.

Which language?  Note that AFAIC .el and .elc files use
2 different languages.

>> - unintern takes a symbol as argument, not a boolean, so it should
>> not be called with the return value of (fboundp ...)
> No, the argument to `unintern' can be a symbol or string.

Who cares, it's still not a boolean.

>> - calling unintern without an obarray arg is a bad idea.
> Yeah,

So: why do you do it?

>> Maybe we should make the second argument mandatory.
> That would be nice.

Indeed.

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

What's weird about it?


        Stefan

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[MON KEY]

On Mon, Sep 13, 2010 at 5:52 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> `#1=', and related reader syntax constructs aren't bad.
>
> In source code, they are.

I'll assume you are speaking only of #=<N> syntax.

> In source code, you have other ways to express sharing, such as `let', which
> are much preferred.

No doubt this is true for "top-level" shared/circular structure.
But what of lisp source code that evaluates to the non-preferred format?
I doubt the distinction is always quite so clear (or detectable).

>
>> Indeed, they are quite prevalent in byte-code files and the language
>> would be hamstrung without them.
>
> Which language?

The one comprised of s-expressions Printed for Read to Evaluate ad nauseam.

> Note that AFAIC .el and .elc files use 2 different languages.
>
>

Hrmmm.
Is there a know non-lisp interpreter for the non-lisp one?
Is it distributed with Emacs?
What is its license?
Where can I find its source code?

>> No, the argument to `unintern' can be a symbol or string.
>
> Who cares, it's still not a boolean.

So would you agree then that where `fboundp' shouldn't take a boolean neither
should `unitern'?

>
>>> - calling unintern without an obarray arg is a bad idea.
>> Yeah,
>

This elision conveniently ignores my caveats w/re the current use value of
Emacs "other" obarrays...

>
> So: why do you do it?
>

Why do i do what, unintern? To unintern a symbol of course :P
More specifically, redefining button-types and faces are good uses.

>> Yeah, but again there is the weird corner case of interning the 0
>> length string.
>
> What's weird about it?

Whats not?

(identity (intern ""))
;=>

(put (identity (intern-soft ""))
     (identity (intern-soft ""))
     (identity (intern-soft "")))
;=>

(get (identity (intern-soft ""))
     (identity (intern-soft "")))
;=>

(setq 0len (symbol-plist (identity (intern-soft ""))))
;=> ( )

(symbol-value '0len)
=> ( )

(car (symbol-value '0len))
=>

More specifically, what is the utility?

>
>        Stefan
>

On Mon, Sep 13, 2010 at 5:52 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> `#1=', and related reader syntax constructs aren't bad.
>
> In source code, they are.  In source code, you have other ways to
> express sharing, such as `let', which are much preferred.
>
>> Indeed, they are quite prevalent in byte-code files and the language
>> would be hamstrung without them.
>
> Which language?  Note that AFAIC .el and .elc files use
> 2 different languages.
>
>>> - unintern takes a symbol as argument, not a boolean, so it should
>>> not be called with the return value of (fboundp ...)
>> No, the argument to `unintern' can be a symbol or string.
>
> Who cares, it's still not a boolean.
>
>>> - calling unintern without an obarray arg is a bad idea.
>> Yeah,
>
> So: why do you do it?
>
>>> Maybe we should make the second argument mandatory.
>> That would be nice.
>
> Indeed.
>
>>> 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.
>
> What's weird about it?
>
>
>        Stefan
>

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[Stefan Monnier]

>> In source code, they are.
[...]
> No doubt this is true for "top-level" shared/circular structure.
> But what of lisp source code that evaluates to the non-preferred format?

If it's the result of some evaluation, then it's not source code any more.

>>> Indeed, they are quite prevalent in byte-code files and the language
>>> would be hamstrung without them.
>> Which language?
> The one comprised of s-expressions Printed for Read to Evaluate ad nauseam.

sexpressions are just a syntax for data.  For code you need an
additional layer of syntax which decides which s-expression mean what.

I.e. Elisp is not just "any S-expression" but a particular subset.

>> Note that AFAIC .el and .elc files use 2 different languages.
> Is there a know non-lisp interpreter for the non-lisp one?

There is "Lisp interpreter for the byte-code", just like there is no
Lisp interpreter for assembly code.  A Lisp interpreter interprets Lisp,
by definition.  And byte-code is not Lisp, even if it was designed
specifically as the output of a byte-compiler whose input is Lisp.

>>> No, the argument to `unintern' can be a symbol or string.
>> Who cares, it's still not a boolean.
> So would you agree then that where `fboundp' shouldn't take a boolean neither
> should `unitern'?

I'm not sure what you mean.  Among other things it's very unclear what
you mean by "shouldn't" and by "take a boolean".

>>>> - calling unintern without an obarray arg is a bad idea.
>>> Yeah,
> This elision conveniently ignores my caveats w/re the current use value of
> Emacs "other" obarrays...

I've just installed a change in emacs-23 which makes the obarray arg
mandatory (well, old uses still work, but the byte-compiler will
complain about them).

>> So: why do you do it?
> Why do i do what, unintern? To unintern a symbol of course :P
> More specifically, redefining button-types and faces are good uses.

If you need to unintern them to do that, it's a bug.

>>> Yeah, but again there is the weird corner case of interning the 0
>>> length string.
>> What's weird about it?

> Whats not?

> (identity (intern ""))
> ;=>

> (put (identity (intern-soft ""))
>      (identity (intern-soft ""))
>      (identity (intern-soft "")))
> ;=>

> (get (identity (intern-soft ""))
>      (identity (intern-soft "")))
> ;=>

> (setq 0len (symbol-plist (identity (intern-soft ""))))
> ;=> ( )

> (symbol-value '0len)
> => ( )

> (car (symbol-value '0len))
> =>

> More specifically, what is the utility?

None of this seems weird at all.  The only problem I see is that we
don't have a valid printed (and readable) representation for it.


        Stefan

Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth

[MON KEY]

On Mon, Sep 20, 2010 at 11:56 AM, Davis Herring <herring@lanl.gov> wrote:
>
> Why are you wrapping everything in `identity'?  That function, by
> definition, doesn't change anything.
>

It was intended to be illustrative that there is no "identity".

> Davis