On Sun, Dec 24, 2023 at 6:10 PM Ihor Radchenko <
yantar92@posteo.net> wrote:
>
> João Távora <
joaotavora@gmail.com> writes:
> >> > [ Tangent: one thing I notice is that the expansion in ox-html.el is
> >> > buggy. It evaluates the keyword arguments to the macros multiple times
> >> > for no effect. The solution would be to change the macro calling
> >> > convention to be:
> >> >
> >> > (cl-defmacro org-export-with-buffer-copy ((&key to-buffer drop-visibility
> >> > drop-narrowing drop-contents
> >> > drop-locals
> >> > &allow-other-keys) &body body)
> >> > ...)
> >>
> >> May you elaborate?
> >
> > Just expand the macro as in ox-html.el and see for yourself.
>
> Hmm... It actually looks like a problem with `cl-defmacro' rather than
> with macro definition itself.
No, Common Lisp's DEFMACRO works exactly like this. You need to understand how &rest works with &key and &allow-other-keys. It _also_ keeps the keys. That's just how it works.
> >> > `(org-export--call-with-buffer-copy (lambda () ,@body)
> >>
> >> AFAIU, this technique will prevent compiler optimizations, won't it?
> >
> > What compiler optimizations are you talking about? The only
> > price to pay is an extra funcall. "We can solve any problem by
> > introducing an extra level of indirection." The function compiled,
> > where presumably the complicated optimization-worthy logic lies
> > is still compiled.
>
> Any use of (funcall 'symbol ...) means that compiler is not able to know
> the function slot of 'symbol at compile time, because it may change.
> Hence, any optimization that relies upon knowing both the context of the
> funcall and the internals of 'symbol will become impossible.
It's not even a symbol that is in question. And whatever this function-calling, it is more than probably dwarved by the cost of the remaining macro expansion. If you were making, say, a sequence processing library it would have to be measured. But here I'm 99.9% sure there's no efficiency downside. Just in allocation costs alone, your macro creates buffers, copies things, etc and then there's the expanded body. Just fixing the bug I've found will more than pay for it likely.
> And this will not solve the problem when Org files are loaded in mixture
> from Emacs built-in version and from some other version (ELPA, manually
> installed Org mode, etc).
That is a different problem with a different solution, and it only affects those who update Org from ELPA. There are many problems in the world, you can't expect a single solution to fix them all. That other problem, for example, has nothing to do with macro expansion site recompilation. I'm only targeting _that_ one for now, because that is what directly affects developers or anyone working with an Emacs from master.
João