Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code]

[Garreau, Alexandre]

Le 06/10/2018 à 21h24, tomas@tuxteam.de a écrit :
> On Sat, Oct 06, 2018 at 06:55:54PM +0200, Garreau, Alexandre wrote:
>> Or would “reevaluate every function that where defined with the
>> (now-redefined) inlined function inside” work too?
>
> Hmm. Not reevaluate, but recompile, and not "inside", but rather
> "outside" -- like finding all places where this function was
> inlined 

I don’t get how “outside” is the correct form here, as this is precisely
what I was meaning: I mentioned it in my other message titled “Knowing
where a function has been used (e.g. for optimizing)” (message-id: [0],
url: [1]), as I found a such functionality, symetrical to
find-definition, would be quite generally useful for lot of stuff.

> and do some magic there.

What other kind of magic than (maybe recursively)
reevaluating/recompiling could be needed there?

> Perhaps doable, but not trivial.

I have really no precise idea of where and how is stored the place where
each function was defined wrt the related function’s symbol (I tried to
search somewhere ago and found it must be linked with load-history, but,
because of the absence of a such feature ^^, I don’t know where and how
it is updated, without further searching (by grepping?)), but would it
be so hard storing a symbol at the right place (near the place where it
is said where that symbol is defined (and/or other informations about
this symbol)) for each function (why not also variable or even macro?
symbol generically) refered in the function body?

>> Why “undo”? [...]
>
> because...
>
>  - when debugging, you want to know that function "foo" is being
>    called
>  - you want, perhaps, to advice/instrument the function after its
>    entrails have been spread across some other byte code
>  - because you expect it to be possible to redefine the function
>    at run time (the run time system would have to know how to
>    excise the inlined and perhaps optimised bits and pieces and
>    replace them by something else)

So, except maybe wrt debugging (which there should imply reevaluation,
like with edebug-defun), reevaluating (or rather recompiling indeed,
since afaiu then, simple evaluation will never optimize anything, unlike
byte-compiling (right?)).

[0] <9oqtevzzzzzz.yga.xxuns.g6.gal_-_@portable.galex-713.eu>
[1] https://lists.gnu.org/archive/html/help-gnu-emacs/2018-10/msg00068.html