all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
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 22:03:32 +0300	[thread overview]
Message-ID: <83pnvwo7i3.fsf@gnu.org> (raw)
In-Reply-To: <jwvk1m4futf.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Fri, 26 Oct 2018 14:23:26 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Oct 2018 14:23:26 -0400
> 
> >> 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.

I disagree.  We describe our code, not what the compiler produces out
of it.

> >   ‘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.

Where does it say something that has that effect?

> 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.

So you now agree to describe in detail what predicate is used for each
data type?  I'm okay with that; I proposed the above because I
interpreted your original response as an objection to such detail.



  parent reply	other threads:[~2018-10-26 19:03 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
2018-10-26 19:00           ` Paul Eggert
2018-10-26 19:37             ` Stefan Monnier
2018-10-26 19:03           ` Eli Zaretskii [this message]
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=83pnvwo7i3.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.