Re: pure-fns in byte-opt.el

[Philipp Stephani <p.stephani2@gmail.com>]

Am Sa., 25. Juli 2020 um 21:58 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> of any use.  The only *real* definition is the last part: "the compiler
> >> can precompute the call if it knows the arguments" (where "can" should
> >> probably be replaced with "may", actually).
> > That's not a very useful definition, though, or rather, not a
> > definition at all, but a consequence of an as-yet hidden definition.
>
> I don't see why you think so.

It requires the user to know how the byte optimizer operates (or at
least, how it can operate in theory).

>
> > It has to be possible to decide whether a function is pure by looking
> > at its observable behavior and its definition.
>
> The above "definition" seems to allow that: based on looking at the code
> you should be able to assess whether it's safe to allow the compiler (or
> anything else for that matter) to precompute the call.

I wouldn't know how that should be possible without knowing how the
compiler operates (or what it "knows" or can know).

>
> > The behavior of the byte compiled needs to follow
> > from the definition, not the other way round.
>
> I don't see how the above definition fails this constraint.
>

It relies on some (rather vague) terms about the compiler, such as
"precompute" and "know". What if we change the compiler significantly
so that it "knows" much more? Wouldn't that suddenly change the
possible set of pure functions?