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

From: Mattias Engdegård <[email-masked]>
Date: Thu, 2 Jul 2020 12:26:51 +0200

1 juli 2020 kl. 23.31 skrev Andrea Corallo <[email-masked]>:

> Another reason why I'm interested is that I reuse these
> definitions in the native compiler.

In that case there are probably more functions you may want to consider for purity -- what about:

< > <= >= = /=
string< string= string-equal
eq eql equal
proper-list-p
identity
memq memql member
assq assql assoc

> I guess for the most part I can just include the one I've missed.

By all means, but do not take my word for the correctness of my list -- think it through yourself. We mustn't err here.

> I'm not only sure about the one operating on lists like `length' given the
> list may be modified in the runtime (?).

Not sure why this would be an obstacle, but I could have overlooked something important! Could you explain your thinking in greater detail, and if possible provide an example of code that you think might be miscompiled if 'length' or 'safe-length' were marked pure?

I still wonder if there is any reason to limit arithmetic constant folding to the portable fixnum range. Given that we don't evaluate fixnump or bignump at compile-time, what observable effects would constant-folding, say, (ash 1 32) have? Advice from deeper thinkers solicited!