bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mattias Engdegård
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Sun, 5 Jul 2020 15:00:32 +0200

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.

Attachment: 0001-Mark-more-functions-pure-bug-42147.patch
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]