From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums
Date: Fri, 26 Oct 2018 14:23:26 -0400 [thread overview]
Message-ID: <jwvk1m4futf.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83va5ooboc.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Oct 2018 20:33:23 +0300")
>> >> > Stefan, this change needs a suitable change in the docs (both the doc
>> >> > string and the ELisp manual): they still claim integers are compared
>> >> > using 'equal', which AFAIU is now inaccurate.
>> >> AFAIK using `eql` gives the same result as comparing with `equal`:
>> >> It's just an internal optimization that is transparent to the user.
>> > That's so, but I find documentation that explicitly calls out 'equal'
>> > misleading when the code actually invokes 'eql' instead.
>> I don't understand why you feel that way.
> "Feel"? The text refers to 'equal' explicitly, so it's not a feeling,
> it's a fact.
You say "find ... misleading", which I consider to describe a feeling
of yours. Not that it matters, tho. Personally I don't find it
misleading at all, as long as I can indeed rely on the fact that the
code will always behave *as if* it used `equal`.
>> Would you feel the same if `pcase` always used `equal` and the
>> optimization to `eql` were performed in the byte-compiler instead?
> I don't know, and it's not really relevant, is it?
It is: the use of `eq` or `eql` here is an optimization which pcase
performs only because the compiler doesn't do it.
To me as a user, whether such an optimization is performed in the macro
expander or in the byte-compiler is irrelevant (as long as the
optimization is correct and I hence can't tell the difference).
It's also relevant in the sense that all things being equal it would be
better for this optimization to be performed in the byte-compiler (so
that it applies not only to pcase code but to other code as well).
So instead of changing the pcase doc, we could move the optimization to the
byte-compiler.
> How about this:
>
> ‘KEYWORD’
> ‘INTEGER’
> ‘STRING’
> Matches if EXPVAL is equal to the literal object. The equality
> predicate depends on the type of the object; e.g., symbols are
> compared using 'eq', and strings using 'equal'.
I think we should say here that the semantics is that of `equal` and not
that of `eq` (or `=` or whatever else).
The above would allow `pcase` to use `eq` for integers. IOW if pcase
uses `eq` on integers (as it did until yesterday) and some code uses
pcase to match a bignum, the above would let us say that the bug is in
the pcase use rather than in the pcase implementation.
Compared to the current doc, it also leaves it unclear whether 1.0 would
match the '1 pattern.
Stefan
next prev parent reply other threads:[~2018-10-26 18:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 9:03 [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums Eli Zaretskii
2018-10-26 14:17 ` Stefan Monnier
2018-10-26 15:02 ` Eli Zaretskii
2018-10-26 16:04 ` Stefan Monnier
2018-10-26 17:33 ` Eli Zaretskii
2018-10-26 18:23 ` Stefan Monnier [this message]
2018-10-26 19:00 ` Paul Eggert
2018-10-26 19:37 ` Stefan Monnier
2018-10-26 19:03 ` Eli Zaretskii
2018-10-26 19:37 ` Stefan Monnier
2018-10-27 12:15 ` Andy Moreton
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=jwvk1m4futf.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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.