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

[Philipp Stephani]

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.