all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lynn Winebarger <owinebar@gmail.com>
To: Philip Kaludercic <philipk@posteo.net>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Cc: help-gnu-emacs@gnu.org
Subject: Re: inline function expansion
Date: Thu, 11 May 2023 03:11:14 -0400	[thread overview]
Message-ID: <CAM=F=bAsVyhMN2JEaqsExBb9_G4c52ABoXqX5m+-_WtrBDHnYQ@mail.gmail.com> (raw)
In-Reply-To: <87bkivhqip.fsf@posteo.net>

On Sun, May 7, 2023 at 3:48 PM Philip Kaludercic <philipk@posteo.net> wrote:
> Lynn Winebarger <owinebar@gmail.com> writes:
> > 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?

I was working off of the description in "Evolution of Emacs Lisp",
page 45, which gives the example of cl-type-p for evaluation of
constant expressions at compile-time via inline functions (figure 2):
(define-inline cl-typep (val type)
  (inline-letevals (val)
    (pcase (inline-const-val type)
      (`(not ,ty)
       (inline-quote (not (cl-typep ,val ',ty))))
      (`(eql ,v)
       (inline-quote (eql ,val ',v)))
      (`(satisfies ,pred) (inline-quote (funcall #',pred ,val)))
      ((and (pred symbolp) ty (guard (get ty 'cl-deftype-satisfies)))
       (inline-quote (funcall #',(get ty 'cl-deftype-satisfies) ,val)))
      ...
     (ty (error "Bad type spec: %s" ty)))))

The info documentation does not include any examples involving
inline-const-p, and in fact, I cannot find any code in the emacs lisp
directory, or in the source of a couple of thousand packages, that
makes use of inline-const-p or inline-const-val *other* than this
exact function.

I'd like to define inline- variants of pure subrs, e.g. arithmetic
operators, type-predicates, that evaluate during macroexpansion rather
than involving the compiler's optimization phase.  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.  Unfortunately, I don't see how I can write something like
(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))))

Admittedly, I haven't actually tried the code above, but if I
understand the define-inline macro, the defun would include the "if"
statement, and that is not the intension.

I can still define the kind of inlined primitives described above
using a macro based on define-inline's approach of defining a compiler
macro and a defun, but I'm not seeing how to use the existing inline-*
machinery to do it.  Am I missing something?

Lynn



  parent reply	other threads:[~2023-05-11  7:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-07 14:32 inline function expansion Lynn Winebarger
2023-05-07 17:51 ` Basile Starynkevitch
2023-05-07 19:48 ` Philip Kaludercic
2023-05-07 20:16   ` Lynn Winebarger
2023-05-08  0:21     ` Emanuel Berg
2023-05-08 11:12       ` Lynn Winebarger
2023-05-08  2:03   ` Lynn Winebarger
2023-05-11  7:11   ` Lynn Winebarger [this message]
2023-05-12  6:25     ` Emanuel Berg
2023-05-18 14:56     ` Lynn Winebarger
2023-05-19 13:31       ` Stefan Monnier
2023-05-20 14:18         ` Lynn Winebarger
2023-05-20 15:32           ` Stefan Monnier
2023-05-21 12:47             ` Lynn Winebarger
2023-05-18 18:29     ` Stefan Monnier
2023-05-19  0:22       ` Lynn Winebarger
2023-05-19 13:07         ` Stefan Monnier
2023-05-20 15:01           ` Lynn Winebarger
2023-05-20 15:48             ` Stefan Monnier
2023-05-27 14:34               ` Lynn Winebarger
2023-05-28 14:12                 ` Lynn Winebarger
2023-05-28 14:57                 ` Stefan Monnier
2023-05-28 22:42                   ` Lynn Winebarger
2023-05-29  2:59                     ` Stefan Monnier
2023-06-06 22:38                       ` Lynn Winebarger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM=F=bAsVyhMN2JEaqsExBb9_G4c52ABoXqX5m+-_WtrBDHnYQ@mail.gmail.com' \
    --to=owinebar@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.