bug#13052: 24.3.50; mention recent change of `kbd' to a function in NEWS

[Michael Heerdegen]

"Drew Adams" <drew.adams@oracle.com> writes:

> > It's not related to pure storage, but to whether the function is
> > "pure" (without side effecs). If the function is pure and the
> > arguments satisfy `macroexp-const-p' it is possible to do some
> > optimization during byte-compilation. See lisp/emacs-lisp/byte-opt.el,
> > around line 560 or so.
>
> Thanks.  So I guess that means that if I have a similar (e.g.,
> identical, for discussion) function and I put property `pure' on it
> then I will get the same optimization?

Looking shortly at the code, I see this paragraph, which seems to say it
all:

;; pure functions are side-effect free functions whose values depend
;; only on their arguments. For these functions, calls with constant
;; arguments can be evaluated at compile time. This may shift run time
;; errors to compile time.

So, IIUC, the only optimization you get is that errors happen at
compile-time that would otherwise happen at run-time.  E.g. like for

  (symbol-name "Not-a-symbol")

OTOH, this would become a string when compiled (because it's evaluated
at compile-time):

  (symbol-name 'a-symbol)

> What happens if someone erroneously adds that property to a function
> that is not pure but whose args all satisfy `macroexp-const-p'?  Do
> you just lose the optimization or could something much worse happen?

The funcall and the side-effects happen at compile-time.  In most cases,
this is probably quite bad.

> In any case, this property should be documented.

If I understood the code correctly, this could indeed be a bit useful.
But maybe it is still experimental... it's no big loss not to use it.
And we can be happy that it is no "Do not use this".


Regards,

Michael.