GNU bug report logs - #42147
28.0.50; pure vs side-effect-free, missing optimizations?

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattiase <at> acm.org>, Paul Eggert <eggert <at> cs.ucla.edu>, Andrea Corallo <andrea_corallo <at> yahoo.it>, 42147 <at> debbugs.gnu.org
Subject: bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?
Date: Sat, 25 Jul 2020 22:03:03 +0200

Am Sa., 25. Juli 2020 um 20:10 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > and "side-effect free" is like GCC's "pure." That is, a side-effect
> > free function can dereference pointers stored in Lisp_Objects, but a
> > pure function can't.
>
> I think it's still not very satisfactory since it's written in terms of
> low-level operations in the C code.

Agreed, I'd rather think of this hypothesis as a first step towards a
definition that we can put into the manual.

>
> I think the current intention of our "pure" goes something along the
> lines of: the function will always return the "same" (the sense of `eql`)
> value (or signal the same error) when called with `eql` arguments.
> IOW "the function preserves `eql`ity".
>

That sounds like a very reasonable definition. Do you think it's
equivalent to my hypothesis and/or to the current behavior of the byte
optimizer? Is it a complete definition in the sense that it gives an
unambiguous yes/no answer for every current and future function?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.