Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better, Re: emacs-27 eebfb72 1/2: Document constant vs mutable objects better

[Štěpán Němec]

On Sun, 19 Apr 2020 16:48:46 -0700
Paul Eggert wrote:

> On 4/19/20 3:33 PM, Štěpán Němec wrote:
>
>> Regarding comparing two equal floats, strings or lists by `eq', you warn
>> about its undefinedness ("might not return nil") repeatedly, but can you
>> give an actual example where (eq 1.2 1.2) or (eq "string" "string")
>> returns non-nil in Elisp?
>
>   (let ((str "abc"))
>     (eq str "abc"))
>
> This yields t when byte-compiled.

OK, that's an interesting example, thanks.

I don't think it warrants changing documentation examples like

          (assoc "simple leaves" leaves)
               ⇒ ("simple leaves" . oak)

to

          (assoc (copy-sequence "simple leaves") leaves)
               ⇒ ("simple leaves" . oak)

though, because that's not the point that manual section is making:
what's important here (unlike the modification examples) is not to make
sure the string we're comparing is not the same object as one of the
compared list members. We want to use the appropriate predicate, so that
no matter the object identity, we get the correct result.

So, if you insist that saying that (assq "simple leaves" leaves) returns
nil is no good, how about, rather than giving examples that you would
never use in real code, we change the examples as follows:

          (assq "simple leaves" leaves)
               ⇒ unspecified ; might be nil or non-nil
          (assoc "simple leaves" leaves)
               ⇒ ("simple leaves" . oak)

Similarly for the others.

>> I still think that formulations like "the other arguments (all but
>> the last) should be mutable lists" are unfortunate, because all Elisp
>> lists are mutable.
>
> Pure lists are not mutable. (Admittedly these are getting rare...)
>
>> All lists/strings/vectors are mutable in Elisp.
>
> No, there are exceptions. For example the following makes my Emacs
> dump core, even though all it does is modify a string.
>
>   (aset (symbol-name 'cons) 0 ?x)
>
> It's trying to change the spelling of the name of the 'cons' function,
> but that spelling is in memory that the operating system protects on
> my platform.

This still seems more an issue of terminology: the examples you give IMO
don't illustrate that some strings or lists are mutable and some are
not; it illustrates that mutating some lists or strings has undefined
consequences.

The point I have been trying to make is that, especially now that
immutable (/persistent/functional) data structures are quite widespread,
using the mutable/immutable dichotomy in the way you do for Elisp is
confusing (and I suggest sticking to "undefined consequences" or "safely
mutable"; again: I would expect an attempt to modify an immutable data
structure to produce an error, not dump core or anything else, and I
think that's the general expectation with immutable data structures (and
I still think that saying "all Elisp lists/strings/vectors are mutable"
is valid in that sense).

On Mon, 20 Apr 2020 02:16:03 +0200
Michael Heerdegen wrote:

>> Regarding comparing two equal floats, strings or lists by `eq', you warn
>> about its undefinedness ("might not return nil") repeatedly, but can you
>> give an actual example where (eq 1.2 1.2) or (eq "string" "string")
>> returns non-nil in Elisp?
>
> (eq "" "") => t.  You don't even have to compile.

Yes, but that's a corner case, similar to there only being one empty
list (nil), and I'm not sure it is relevant to the manual sections in
discussion here. I'm not even sure it's relevant (for documentation or
coding style) at all, i.e., you probably wouldn't recommend using (eq
string "") instead of `string-empty-p' or `string='?

>> Otherwise, isn't it too hypothetical/theoretical to talk about in the
>> manual?
>
> It is important.  This once bit me, and it took a long time until I
> found out what was wrong.  I had to ask here (AFAIR that's the reason
> why an explanation was added to the manual).  And it was not code to
> provoke that kind of thing.

Here I assume you mean something else than the empty string case?

-- 
Štěpán