GNU bug report logs -
#42147
28.0.50; pure vs side-effect-free, missing optimizations?
Previous Next
Reported by: Andrea Corallo <andrea_corallo <at> yahoo.it>
Date: Tue, 30 Jun 2020 22:28:02 UTC
Severity: normal
Found in version 28.0.50
Done: Mattias EngdegÄrd <mattiase <at> acm.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
1 juli 2020 kl. 23.31 skrev Andrea Corallo <andrea_corallo <at> 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!
This bug report was last modified 4 years and 281 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.