Re: inline function expansion

[Lynn Winebarger]

On Sun, May 7, 2023 at 3:48 PM Philip Kaludercic <philipk@posteo.net> wrote:
> Lynn Winebarger <owinebar@gmail.com> writes:
>
> > Hi,
> >
> > Is there a function that will let us see the result of inline function
> > expansion at the source level?   I see "byte-compile-preprocess" and
> > "byte-compile-inline-expand" as possibilities, but neither has a
> > docstring.
>
> What I usually do is just to invoke M-x disassemble, but you won't be
> viewing the code transformation on source-level.  I am not sure if
> inlineing happens on a s-expression level like with macros, or if the
> byte-code optimiser just inlines the definition instead of generating
> code funcall.

I know that define-inline uses compiler macros so that the function
symbol is bound to an ordinary function while the compiler interprets
the symbol as a macro.

So, what I'd like is something like compiler-macroexpand-all.

>
> > If I use define-inline, I would like to be able to verify that the
> > result is what I expect, or vice versa, that I understand what the
> > result will be well enough to have the correct expectation.
>
> Isn't the idea of inlining that the behaviour/effect of invoking a
> function shouldn't change, just that the resulting code might be more
> efficient?

The main thing I am interested in is the ability to do compile-time
evaluation on constant expressions.  I'm trying to design/implement a
way of defining generic methods so that the specialization may be
determined (or explicitly constructed) at compile time and compiled to
a non-generic function call, and left to dynamic dispatch otherwise.
I think inline functions, or at least the technique used in
implementing them, will have to be a component in that.  I really need
to be able to see the expanded code to know if I'm using it correctly,
though.   It's something along the lines of the interface-based
generics found in C#, so you can write generic code based on a set of
defined interfaces, and ways to implement those interfaces, then
instantiate those generic methods with particular realizations of the
interfaces.  Then those instantiations would be simple function calls.
On the other hand, the generic function could be called at run time
with objects that are wrapped by a realization of the interface.  They
should both give the same semantics (unless late-binding would cause
different dispatching), but in the former case the composition of the
functions implementing the interfaces would happen by inlining and not
require intermediate allocation of wrapper objects....

Lynn

Lynn