emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Hash consing (was: Re: sqlite3)


From: Drew Adams
Subject: RE: [External] : Re: Hash consing (was: Re: sqlite3)
Date: Sun, 19 Dec 2021 00:27:30 +0000

> > > > some kind of immutable cons data type.
> > >
> > > We already have that:

No, we don't.

> > > for example, the result of evaluating the form
> > > '(1 . 2) is an immutable cons cell.

No, it's not.

> > > The immutability isn't enforced, though:

aka There's no immutability.

> > > passing such a cons cell to `rplaca' will
> > > cause undefined behavior,

Demonstration?  What's undefined about it?

> but typically not signal an error.

> > Sorry, but I don't understand what you're saying.
> > What's immutable about it?  What's undefined
> > about using `setcar' or `rplaca' on it?
> >  (setq x '(1 . 2))
> >  (setcar x 3)
> 
> In general, don't do that.

Right.  Don't mutate that mutable cons.

> In Common Lisp, the consequences are undefined.
> 
> In Emacs Lisp, it does not seem to be put that way,
> see (describe-function 'quote)

I know why one won't want to do it.  It's precisely
because the cons is NOT immutable, and some code
might change it.

Code that mistakenly expects a source code
occurrence of '(1 . 2) to give you a _new_ cons
each time (you think) it's evaluated is bugged,
because it need not, and generally does not, do so.
That's the point of the warning in `C-h f quote'.

There's nothing "immutable" about that cons.
"Don't change this cons", and "don't expect '(...)
to give you a new cons each time", aren't the same
as "it's impossible to change this cons".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]