[Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Eli Zaretskii]

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.

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Stefan Monnier]

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

So, just like we did not document the fact that integers (and symbols)
where actually compared with `eq`, there's no need to document that they
are now compared with `eql`: the intended semantics is to give the same
result as when comparing with `equal` so that's what we document.

The patch simply fixes the (unlikely but possible now) case where the
pattern is an integer that's not a fixnum.


        Stefan

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Fri, 26 Oct 2018 10:17:33 -0400
> 
> > 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.  Maybe we
should make the text less explicit then?

> So, just like we did not document the fact that integers (and symbols)
> where actually compared with `eq`

That we already had misleading docs doesn't mean we need to continue
having misleading docs.

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Stefan Monnier]

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

Would you feel the same if `pcase` always used `equal` and the
optimization to `eql` were performed in the byte-compiler instead?

> Maybe we should make the text less explicit then?

I can't think of any way to make the text less explicit without making
it either too vague or a lot more verbose.  The semantics we want to
promise to the user is exactly that of `equal`, so we'd have to
say something like

    it'll behave like `equal` tho it might use something equivalent
    under the hood anyway

which seems just more verbose with no clear benefit.

To be clear, I'm not opposing such a change: it'd make the doc worse for
me, but I'm ill-placed to judge what's best for the other readers.


        Stefan

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 26 Oct 2018 12:04:11 -0400
> 
> >> > 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.

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

> > Maybe we should make the text less explicit then?
> 
> I can't think of any way to make the text less explicit without making
> it either too vague or a lot more verbose.

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

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Stefan Monnier]

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

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 197 bytes --]

On 10/26/18 11:23 AM, Stefan Monnier wrote:
> I think we should say here that the semantics is that of `equal` and not
> that of `eq` (or `=` or whatever else).

How about the attached doc patch?


[-- Attachment #2: equal.patch --]
[-- Type: text/x-patch, Size: 720 bytes --]

diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi
index 0f7502f1c2..620a079d01 100644
--- a/doc/lispref/control.texi
+++ b/doc/lispref/control.texi
@@ -511,12 +511,13 @@ pcase Macro
 This is known as @dfn{don't care} or @dfn{wildcard}.
 
 @item '@var{val}
-Matches if @var{expval} is @code{equal} to @var{val}.
+Matches if @var{expval} equals @var{val}.
+The comparison is done as if by @code{equal}.
 
 @item @var{keyword}
 @itemx @var{integer}
 @itemx @var{string}
-Matches if @var{expval} is @code{equal} to the literal object.
+Matches if @var{expval} equals the literal object.
 This is a special case of @code{'@var{val}}, above,
 possible because literal objects of these types are self-quoting.
 

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Eli Zaretskii]

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

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Stefan Monnier]

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

Here I disagree: the pcase doc does not describe the generated code, it
only describes the resulting behavior.

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

`eq` is a notion of equality, so "is equal to the literal object" is
a valid description even if we use `eq`.  Futhermore the subsequent text
makes it clear that `pcase` would be free to use whichever notion of
equality it deems appropriate since "The equality predicate depends on
the type of the object".

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

Yes, that's what I've done: `equal` is the predicate used.  ;-)


        Stefan

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Stefan Monnier]

>  @item '@var{val}
> -Matches if @var{expval} is @code{equal} to @var{val}.
> +Matches if @var{expval} equals @var{val}.
> +The comparison is done as if by @code{equal}.
>  
>  @item @var{keyword}
>  @itemx @var{integer}
>  @itemx @var{string}
> -Matches if @var{expval} is @code{equal} to the literal object.
> +Matches if @var{expval} equals the literal object.
>  This is a special case of @code{'@var{val}}, above,
>  possible because literal objects of these types are self-quoting.

Fine by me,


        Stefan

Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums

[Andy Moreton]

On Fri 26 Oct 2018, Eli Zaretskii wrote:

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

Documentation should be describing the fixed semantics of the interface,
not the details of the underlying implementation, nor aspects of the
interface that expose details of the current implementation.

    AndyM