[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pure-fns in byte-opt.el
From: |
Philipp Stephani |
Subject: |
Re: pure-fns in byte-opt.el |
Date: |
Sat, 25 Jul 2020 21:53:14 +0200 |
Am Di., 26. Sept. 2017 um 02:26 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> pure: like side-effect-free but additionally, the function always
> >> returns the same value when called with the same arguments, so the
> >> compiler can precompute the call if it knows the arguments.
> > It may be necessary to define "same" more precisely.
> > Does it mean equal? eq?
>
> Both/neither? The compiler doesn't test it in any way (it only has the
> known arguments, and no "others" to compare it with). I guess `equal`
> is closer to what typically happens, but I don't think this precision is
> 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.
It has to be possible to decide whether a function is pure by looking
at its observable behavior and its definition. Otherwise, how are
programmers to apply the "pure" and "side-effect-free" attributes to
their functions? The behavior of the byte compiled needs to follow
from the definition, not the other way round.
(I know this thread is 3 years old, but the same topic has been
discussed in another thread as well recently, so it's not resolved.
yet)
- Re: pure-fns in byte-opt.el,
Philipp Stephani <=