From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 39557@debbugs.gnu.org
Subject: bug#39557: 27.0.60; Elisp manual, doc about bignums
Date: Wed, 12 Feb 2020 13:36:20 -0800 (PST) [thread overview]
Message-ID: <5fe049c8-18b5-4941-9e34-c320500f49d2@default> (raw)
In-Reply-To: <85imkbyf88.fsf@gmail.com>
> >> I think Drew intended the argument that we should
> >> distinguish them as a sarcastic reductio ad absurdum.
> >
> > Not at all. I wonder why you would think that,
>
> When you said this:
>
> I mean, if you're going to be comparing against a
> literal value, and the doc slants you toward using
> `eq' as it does
>
> since you *don't* want the doc to slant towards `eq',
> I read that paragraph as sarcastic.
The actual quote:
And I don't see where the doc tells you how the Lisp
reader treats an integer numeral - when it gives you
a fixnum and when it gives you a bignum. Shouldn't
it tell you that you get a fixnum whenever the value
is within the fixnum range (if that's in fact the case)?
I mean, if you're going to be comparing against a
literal value, and the doc slants you toward using
`eq' as it does, you'll at least want to know whether
some numeral ends up as a fixnum or a bignum.
There's nothing the least bit sarcastic in any of that.
That point/question is about what happens when a
numeral is read and interpreted by Lisp. It
suggests that we say something about that case.
To use `eq' with a numeral you need to know when
it's handled as a fixnum.
If you use `eql' then that's not a consideration -
you don't really need to know how the numeral is
handled. But since the doc currently, in effect,
promotes the use of `eq' somewhat, providing such
info might help.
There's no reductio ad absurdum there, let alone
a sarcastic one.
Putting this differently, if you compare an integer
against an integer numeral then you had better use
`eql', unless you know that both are fixnums, and
for the latter to be true you need to know how
numerals are handled.
I'm guessing the following rule applies also in
the case of interpreting a numeral - but if so
then maybe it would help to say so explicitly:
if Emacs computes an integer in fixnum range, it
represents the integer as a fixnum, not a bignum.
It's easy to think that a numeral isn't "computed",
and so to not think that this rule applies to a
numeral. At least I, as one reader, wondered how
numerals are handled.
> By the way, this
>
> I'm really surprised this doc got inserted as it is.
>
> is too easily read as a snide jab (I know, you
> didn't mean it that way), so it would be nice if
> you could leave out that kind of meta-opinion
> from future reports.
Is that a meta-opinion on your part? ;-)
I think it may be too easy for you to read it
that way because you're perhaps trying to read
my bug reports that way. Maybe chill a bit?
Actually, I was just expressing my surprise,
as Eli usually shepherds new doc sufficiently
well that such things don't happen. And I
mean that sincerely, as a compliment.
(Darn, another meta-opinion. (Darn, another
meta-meta-opinion that risks being taken as
sarcasm. (Darn, yet another. (D...))))
As for avoiding sarcasm (even humor) in mail:
Sure. But a companion rule of etiquette
might be to avoid attributing malevolence
when a simple, constructive reading will do.
The golden rule implies offering the benefit
of the doubt.
The "you" in my bug report was consistently
the user. The report was technical, not a
rant. It wasn't I who took this to the
personal/meta level. How about we turn now
to the technical content - the problem
reported? Any thoughts on that?
next prev parent reply other threads:[~2020-02-12 21:36 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5fe049c8-18b5-4941-9e34-c320500f49d2@default \
--to=drew.adams@oracle.com \
--cc=39557@debbugs.gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.