4 juli 2020 kl. 18.13 skrev Andrea Corallo <andrea_corallo@yahoo.it>:

> (defun bbb ()
>   (let ((x (list 1 2)))
>     (f x)        ; f is not pure
>     (1+ (car x)) ; <= cannot optimize
>     ))

(A more precise property for 'f' in your examples would be 'side-effect-free' rather than 'pure'.)

> BTW reading the code of the native compiler I realized I am already
> extrapolating for use a very similar list of optimizable functions to the one
> proposed.  I still think would quite cleaner to classify these in
> byte-opt.el.

Certainly, but be sure to state your criteria with clarity. There must be no doubt whether or not a function should have a certain property!

> Attached the updated patch where I'm adding car, car-safe, cdr,
> cdr-safe, max, min.

Thank you Andrea! Attached is an update with the following modifications:

* I tried to segregate pure functions that operate on mutable objects, such as car, length and equal, from the rest. This way we can more easily separate them entirely (using different properties) later on if desired.

* The list of pure functions was expanded further. Related functions were grouped rather than ordered alphabetically, because I found it easier to read this way -- you may disagree.

* 'expt' was prudently removed because it doesn't necessarily give portable results for arbitrary floating-point arguments. (exp, sin etc were not included either for the same reason.)

* It turned out that in order to bootstrap, we have to prevent the constant evaluation in the byte compiler from raising errors on invalid input. For example, the macro dired-map-over-marks expands to (essentially)

	     (if (integerp ARG)
		 (< ARG 0)

where ARG is a macro argument that can be nil. Since < is now pure, compilation would fail despite the offending code being unreachable. As this style of code exists and is not unreasonable, the error has to be suppressed.