bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Philipp Stephani]

Am Fr., 3. Juli 2020 um 11:25 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> 2 juli 2020 kl. 21.09 skrev Philipp Stephani <p.stephani2@gmail.com>:
>
> > I don't think most of those are pure, as they have to "look into" an
> > object. For example, the result of "equal" does not only depend on the
> > argument objects, but also the objects they refer to.
>
> Unless I'm mistaken, they are pure enough for the purpose of constant 
> folding, where the arguments are already known (constant) at compile-time; do 
> come with a counter-example if you disagree.
>
> Were you thinking about other uses of pure functions? Perhaps our notion of 
> purity is underspecified.
>

Yes, I think so. The term is mentioned in the Lisp manual, but I've
always had trouble deciding whether a given function was pure or not.
To be useful, the definition shouldn't depend on what the byte
compiler happens to do; rather, we need to formally define purity (and
side effect-freedom) based on the observable behavior of the function
in question alone and then adapt the behavior of the byte compiler to
the definition, if necessary.
My working hypothesis is that "pure" is like GCC's "const"
(https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)
and "side-effect free" is like GCC's "pure." That is, a side-effect
free function can dereference pointers stored in Lisp_Objects, but a
pure function can't. So functions like consp or eq are pure, while car
or equal are merely side-effect free. eql is a bit of an exception, as
floating-point objects and big integers are truly immutable, so it
probably also qualifies as pure using this definition.