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

["Mattias Engdegård" <mattiase@acm.org>]

Actually, pure functions are side-effect-free but not necessarily error-free. But in essence, you are right.

The following functions look like they could be marked pure. Given that they currently aren't, there may be a good reason for their omission -- do correct me!

 integerp
 natnump
 floatp
 characterp
 numberp
 arrayp
 vectorp
 bool-vector-p
 char-or-string-p
 integer-or-marker-p
 keywordp
 number-or-marker-p
 sequencep
 length
 safe-length

... and some more (symbolp, stringp etc) that are already explicitly optimised.

Regarding fixnump, we could add an optimiser since this predicate can be constant-folded for certain arguments, but it's unclear whether it's worth the trouble since this predicate (and bignump) are less commonly used today. Most uses of fixnump (in Emacs) are in Calc, and those are probably relics that should be replaced.

More useful would be the ability to constant-fold ash, expt, %, mod and abs for a subset of each respective domain. I can write a patch.

We could also decide that it's not a problem if an operation returns either a fixnum or bignum depending on the platform, on the grounds that

 (1) the distinction is not directly carried over through numeric constants (bignums and fixnums look the same in .elc files)
 (2) any attempt to discriminate between fixnums and bignums is non-portable anyway (and we can punt the discrimination to runtime)

and thus constant-fold all integer operations (+, -, * etc), not just those resulting in a portable fixnum.