[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inline function expansion
From: |
Lynn Winebarger |
Subject: |
Re: inline function expansion |
Date: |
Thu, 18 May 2023 20:22:53 -0400 |
On Thu, May 18, 2023 at 2:29 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I think it will be easier to ensure compile-time generic methods
> > (e.g. a macro that simply calls a generic method) will (or at least
> > can) dispatch during macro-expansion, without involving the
> > byte-compiler's optimization phase.
>
> I don't understand this, sorry.
I'm trying to provide myself a tool for generic programming that
dispatches at compile time. I've been writing too much repetitive
code, but I'm not a fan of ad hoc macros either. Basically, I'm
trying to provide a C#-ish system for writing generic code
parameterized by interface requirements. Then the generic method can
be moved to compile-time, with specialization on constant parameters
to dispatch to specialized code. Like cl-typep, except instead of an
explicit pcase form, calling a generic method.
> > (define-inline inline-+ (&rest args)
> > (if (seq-every-p #'inline-const-p args)
> > (apply (eval-when-compile (symbol-function '+)) args)
> > (inline-quote (,(eval-when-compile (symbol-function '+)) . ,args))))
>
> IIRC you definitely need an `inline-letvals` somewhere here.
That's the issue - if you use inline-letvals, then the code can't make
use of constant values provided as operands.
> But also this will define the non-inlined version as something along the
> lines of:
>
> (defun inline-+ (&rest args)
> (if (seq-every-p ... args)
> (apply '+ args)
> (apply (symbol-function '+) args)))
>
> which is much too slow IMO.
I agree.
I posted a patch to emacs-devel for define-inline-pure-subr that
adapts the technique of define-inline. I wanted to literally inline
the subr's into the code, but aside from the issue of not having
read-syntax for subrs (for some reason), some parts of core emacs
appear to rely on the car of a form being a symbol.
So I ended up defining a second symbol to hold the true definition,
with the compiler macro inserting a call to that symbol, while the
original symbol made into either a defun or defsubst. The code copies
the plist of the original symbol to the second symbol so any
properties used by the byte-compiler/optimizer will be applied to the
new symbol as well.
- Re: inline function expansion, (continued)
- Re: inline function expansion, Lynn Winebarger, 2023/05/07
- Re: inline function expansion, Lynn Winebarger, 2023/05/11
- Re: inline function expansion, Emanuel Berg, 2023/05/13
- Re: inline function expansion, Lynn Winebarger, 2023/05/18
- Re: inline function expansion, Stefan Monnier, 2023/05/19
- Re: inline function expansion, Lynn Winebarger, 2023/05/20
- Re: inline function expansion, Stefan Monnier, 2023/05/20
- Re: inline function expansion, Lynn Winebarger, 2023/05/21
- Re: inline function expansion, Stefan Monnier, 2023/05/18
- Re: inline function expansion,
Lynn Winebarger <=
- Re: inline function expansion, Stefan Monnier, 2023/05/19
- Re: inline function expansion, Lynn Winebarger, 2023/05/20
- Re: inline function expansion, Stefan Monnier, 2023/05/20
- Re: inline function expansion, Lynn Winebarger, 2023/05/27
- Re: inline function expansion, Lynn Winebarger, 2023/05/28
- Re: inline function expansion, Stefan Monnier, 2023/05/28
- Re: inline function expansion, Lynn Winebarger, 2023/05/28
- Re: inline function expansion, Stefan Monnier, 2023/05/28