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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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