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

[Philipp Stephani <p.stephani2@gmail.com>]

Am Sa., 25. Juli 2020 um 23:00 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> 25 juli 2020 kl. 22.11 skrev Philipp Stephani <p.stephani2@gmail.com>:
>
> > The manual states that
> > "This function [concat] always constructs a new string that is not
> > ‘eq’ to any existing string" so I don't see how it could ever be pure.
>
> Actually that part of the manual was corrected fairly recently, as that statement hasn't been true for decades.
>
> More to the point, the current set of functions marked as 'pure' are really the superset 'pure-absent-mutation': functions that are pure when it can be assumed that the arguments are not modified. This assumption can be based on physical immutability (integers), by convention (string constants), or anything else the compiler can prove such as control flow.
>
> There is also the question of what equality to use and here the answer is probably 'equal' since we are only dealing with immutables. (The return values of these functions cannot be considered mutable for obvious reasons, so make-string is out.)
>
> If you want to rename the property accordingly then I won't object. In any case, it is certainly a good idea to be precise about what the various sets really mean.

It looks like these are really two separate concepts, which should be
documented separately and should get separate function properties:
- Fully-pure functions are guaranteed to either return results that
are "eql" or signal error data that is "equal-including-properties"
when given arguments that are pairwise "eql", for all possible
arguments, mutable or not.
- Pure-unless-mutable functions are a strict superset whose
restrictions to immutable arguments are guaranteed to either return
results or signal error data that are "equal-including-properties"
when given arguments that are immutable and pairwise
"equal-including-properties".
Both categories must be free of observable side effects as well.

>
> There are also some functions declared 'pure' that appear to have side effects: kbd, package-get-version
>

kbd can and should be made pure-unless-mutable at least.
package-get-version should be neither, but should be marked using a
third to-be-introduced property (e.g. "eval-when-compile") to state
the intention without resorting to hacks.