> Why? Its return value clearly only depend=
s on its argument, and it doesn't
> change any global state. It's the poster child of a pure function!=
=C2=A0 (let ((s (make-string 5 ?a)))
=C2=A0 =C2=A0 (list (string-to-char s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (aset s 0 ?b)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (string-to-char s))))
If string-to-char were a pure function, it would return the same value
in both calls (since the arguments are `eq').
Hmm. I get the argument, but wouldn=
9;t that mean that only a tiny set of builtins were pure? If the definition=
is "A function is pure if applying it to the same objects (in the sen=
se of `eq') always gives the same result", then I think only eq, e=
ql, null, and the type predicates (integerp etc.) are pure. Even the arithm=
etic functions aren't pure because they can act on (mutable) markers. T=
he list in byte-opt, however, is noticeably different, and none of the func=
tions marked pure there are actually pure. The same applies to third-party =
libraries such as dash.el.
In any case, the precise definition of=
"pure" and "side effect free" needs to be in the manua=
l, and functions that are wrongly declared as pure or side effect free need=
to be fixed.=C2=A0