Three questions about pcase for Stefan

Three questions about pcase for Stefan

[Michael Heerdegen]

Hi Stefan,

1.  The following raises an error:

(pcase 1.0
  (1.0 t))

i.e., floats do not count as "atom".  This is consistent, also explained
correctly in the doc, but may nonetheless be confusing.  What led you to
this decision?


2.  Do you think we can already bury the old deprecated special behavior
of the atoms nil and t as patterns?


3.  Is it correct to say that not only the functions used in a pred
pattern, but any ordinary Lisp code part of any pattern (guard, app,
let, etc.) should be pure in the same sense?


Thanks,

Michael.

Re: Three questions about pcase for Stefan

[Stefan Monnier]

> i.e., floats do not count as "atom".  This is consistent, also explained
> correctly in the doc, but may nonetheless be confusing.  What led you to
> this decision?

Testing equality of floating point numbers is very rarely correct.

> 2.  Do you think we can already bury the old deprecated special behavior
> of the atoms nil and t as patterns?

Far from that.  IIUC, it's even still used in a GNU ELPA package.
We'll have to live with it for a reasonably long time.
And to tell you the truth, I don't think it's a great idea to make nil
and t match themselves.  We can plan on making them signal errors, OTOH
(for Emacs-26.1 or Emacs-27.1).

> 3.  Is it correct to say that not only the functions used in a pred
> pattern, but any ordinary Lisp code part of any pattern (guard, app,
> let, etc.) should be pure in the same sense?

Yes.


        Stefan

Re: Three questions about pcase for Stefan

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > 2.  Do you think we can already bury the old deprecated special
> > behavior of the atoms nil and t as patterns?
>
> Far from that.  IIUC, it's even still used in a GNU ELPA package.
> We'll have to live with it for a reasonably long time.

Mmh, ok.

> And to tell you the truth, I don't think it's a great idea to make nil
> and t match themselves.

Why?  It would be quite useful in practice, and fit perfectly into the
rest of the semantics.  Of course one can still quote them...


Michael.

Re: Three questions about pcase for Stefan

[Paul Eggert]

Stefan Monnier wrote:
> Testing equality of floating point numbers is very rarely correct.

Although it's rarely correct in programs written by newbies, it's almost always 
correct in floating-point programs written by experts. Is pcase for newbies 
only, or for experts as well?

RE: Three questions about pcase for Stefan

[Drew Adams]

> > Testing equality of floating point numbers is very rarely correct.
> 
> Although it's rarely correct in programs written by newbies, it's
> almost always correct in floating-point programs written by experts.

Really?  Care to give an expert example of what a `pcase' user
would need to do?

What users typically do for this, AFAIK, is to test that the
given floating-point number is within a certain range.  Even
experts don't test equality using `equal' and such, AFAIK.

Re: Three questions about pcase for Stefan

[Stefan Monnier]

>> Testing equality of floating point numbers is very rarely correct.
> Although it's rarely correct in programs written by newbies, it's almost
> always correct in floating-point programs written by experts.

1- we can assume that an expert would only write correct code, so yes
   they'd only do it when it's correct, but since it's rarely correct,
   they'd only use it very rarely.
2- instead of "1.0" the experts can write "'1.0".


        Stefan

Re: Three questions about pcase for Stefan

[Stefan Monnier]

>> And to tell you the truth, I don't think it's a great idea to make nil
>> and t match themselves.
> Why?  It would be quite useful in practice, and fit perfectly into the
> rest of the semantics.

Because, as history has shown, there are other "intuitive/natural"
semantics for t and nil here, so I think it's better to just reject
those patterns and avoid any possible confusion.

> Of course one can still quote them...

Indeed, and it's so easy to do, that I don't see much benefit in letting
people drop the quote.


        Stefan