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

[Mattias Engdegård]

1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo@yahoo.it>:

> 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!