all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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 15:19:54 -0800 (PST)	[thread overview]
Message-ID: <216cb392-3b01-466d-8fa2-eabcba3283cd@default> (raw)
In-Reply-To: <8c6ed478-db97-8abc-de79-f5c10498ad0c@cs.ucla.edu>

Thanks for working on this.

> > That's really the _last_ thing we should tell users, not the first.
> 
> I installed the first attached patch to move the distinction between fixnums
> and
> bignums to the end of the section.

Thanks.

> > 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)?
> 
> It already said that, but apparently not clearly enough. I installed the
> second
> attached patch to try to make things clearer.

Thanks.

> > this doc should probably also mention that the numerical value of
> > a marker is an integer
                   ^^^^^^^
> It already says "Many of the functions described in this chapter accept
> markers for arguments in place of numbers.... When the argument value
> is a marker, its position value is used and its buffer is ignored."

Not really the same thing.  Nothing there says that
a marker position is an integer (fixnum or bignum),
and not some other kind of number.

Sure, many readers will know (but not from here)
that buffer positions are integers.  And they can
guess that marker positions are buffer positions,
hence integers...  But it's not hard to tell them
that the numerical value of a marker is an integer.

(This isn't a big deal.  I said "should probably
also mention".  I could have said "maybe".  Just a
suggestion.)

> > if you compare an integer
> > against an integer numeral then you had better use
> > `eql', unless you know that both are fixnums
> 
> 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.

As for the proposed changes -

If we're going to talk about "older" code then
we should specify older than what.  I don't
think there should be any need to talk about
older code or say "should now".  The general
rule's simple: use `eql' - worked before,
works now.

If some code uses `eq', it couldn't possibly
have worked before with two integers big
enough to now be bignums, right?  Any code -
old or new - that uses `eq' to compare
integers needs to know that at least one of
the operands is a fixnum.

We should just say that you can use `eql' to
compare any integers, and add that you can't
use `eq' to compare integers if they're both
bignums.  How complicated is that?

Emphasize `=' and `eql'.  `eq' should just be
a footnote.  That's my suggestion.





  reply	other threads:[~2020-02-17 23:19 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 [this message]
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=216cb392-3b01-466d-8fa2-eabcba3283cd@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 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.