From: Drew Adams <drew.adams@oracle.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Noam Postavsky <npostavs@gmail.com>, 39557@debbugs.gnu.org
Subject: bug#39557: 27.0.60; Elisp manual, doc about bignums
Date: Mon, 17 Feb 2020 17:52:41 -0800 (PST) [thread overview]
Message-ID: <9da8663c-083e-4d3f-a706-26744feac1f0@default> (raw)
In-Reply-To: <8deb3c37-79a4-b10f-87ed-6265dedb07d7@cs.ucla.edu>
> >> No, it suffices if *either* is a fixnum. For example, (eq 0 FOO) tests
> >> whether
> >> FOO is the integer zero, and works regardless of whether FOO is a bignum.
> >
> > I see. Then please say that.
>
> I'd rather not. Again, this section is "Integer Basics" and the reference
> manual
> should not bog itself down various possible ways to use integers in programs
> (there are too many ways).
Then remove all mention of `eq', if you don't
specify how it behaves with bignums.
> > If we're going to talk about "older" code then
> > we should specify older than what.
>
> I originally wrote "older than Emacs 27" but trimmed it as being
> nonessential
> before installing the patch. It's not a big deal either way.
If it means nothing to say "older code" then
remove it altogether. The hand waving just
confuses.
> > I don't
> > think there should be any need to talk about
> > older code or say "should now".
>
> This bug report assumed that Emacs is basically like Common Lisp in this
> area.
No, it doesn't. Whatever Emacs Lisp users need
to know about integers is what they should be
told. If they need to be told something about
`eq' then tell that.
> However, Emacs is not there yet (though we've made progress), and it's
> better if
> the documentation reflects that fact rather than pretending there's no
> difference from Common Lisp.
AFAIK, I didn't say anything that contradicts that.
I'd never suggest that Emacs Lisp doc pretend that
Emacs Lisp is the same as Common Lisp where it's
not.
I mentioned CL because its doc is clear wrt the
use of `eql' for numbers. If the Emacs doc can't
say the same thing, that's fine; it should say
what it needs to say, to make clear its own
behavior. It shouldn't waffle or confuse users.
> > Any code -
> > old or new - that uses `eq' to compare
> > integers needs to know that at least one of
> > the operands is a fixnum.
>
> It's sometimes OK to use eq even when both arguments are bignums. It depends
> on the circumstances.
Either it's important to say how `eq' behaves with
bignums or it's not.
If it is, then users deserve the straight info.
If it's not, why talk about `eq' at all? In that
case, why not just tell users to compare integers
using `eql' or `='?
You seem to be trying to have your cake and eat
it too. You seem to want to talk about `eq' in
the context of integers, but you apparently don't
want to say how it behaves.
I don't see how that helps users. My suggestion
is to either (1) really say what the deal is with
`eq' wrt integers (but not as the first thing we
say about integers - you've already moved it,
which is good) or (2) say nothing about it, other
than to recommend against using it and for using
`eql'.
Figure out what the real message is for users,
about using `eq' with integers - what they should
be told. Then communicate it.
next prev parent reply other threads:[~2020-02-18 1:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 23:55 bug#39557: 27.0.60; Elisp manual, doc about bignums Drew Adams
2020-02-11 17:01 ` Eli Zaretskii
2020-02-11 21:46 ` Noam Postavsky
2020-02-11 22:34 ` Drew Adams
2020-02-12 15:53 ` Noam Postavsky
2020-02-12 21:36 ` Drew Adams
2020-02-13 18:23 ` Noam Postavsky
2020-02-13 21:03 ` Drew Adams
2020-02-12 20:06 ` Richard Stallman
2020-02-13 23:43 ` Richard Stallman
2020-02-17 22:05 ` Paul Eggert
2020-02-17 23:19 ` Drew Adams
2020-02-17 23:52 ` Paul Eggert
2020-02-18 1:52 ` Drew Adams [this message]
2020-02-18 3:13 ` Paul Eggert
2020-09-25 11:18 ` Lars Ingebrigtsen
[not found] <<3d420026-bb32-413f-9a9c-304240aa82e2@default>
[not found] ` <<8336bhrrb4.fsf@gnu.org>
2020-02-11 18:26 ` Drew Adams
2020-02-11 19:14 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9da8663c-083e-4d3f-a706-26744feac1f0@default \
--to=drew.adams@oracle.com \
--cc=39557@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).