From: Lynn Winebarger <owinebar@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Philip Kaludercic <philipk@posteo.net>, help-gnu-emacs@gnu.org
Subject: Re: inline function expansion
Date: Sun, 21 May 2023 08:47:23 -0400 [thread overview]
Message-ID: <CAM=F=bCAWxsPPT21_KJos7OKiphnKe5HqK4-UPVCkmqhX9okqA@mail.gmail.com> (raw)
In-Reply-To: <jwva5xzt4wg.fsf-monnier+emacs@gnu.org>
On Sat, May 20, 2023 at 11:32 AM Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> >> You're right, tho in practice number is either nil or non-constant, so
> >> it doesn't make much difference.
> > I'm just pointing out it is difficult to tell how to use the
> > facilities for compile-time evaluation provided by define-inline.
>
> Oh, that, yes the `define-inline` facility is hard to use, no doubt.
> I'm not happy with it. This is also reflected in the lack of doc
> because it's difficult to document it much better than "look at the
> code, try it out, and fiddle until it works" :-(
Couldn't most (all but 2) of the current instances be captured by a
simplified interface defsubst* defined along the lines of:
(defmacro defsubst* (name args &rest body)
(let ((parameters (inline--get-parameters args)))
`(define-inline ,name ,args
(inline-letevals
,(inline--susbt*-bindings args)
(inline-quote
(cl-symbol-macrolet
,(mapcar (lambda (v) `(,v (,'\, ,v))) parameters)
,@body))))))
Where I've left the ugly details of handling lambda lists to
inline--get-parameters and inline--subst*-bindings. I'm unclear on
why defsubst* is an improvement on defsubst.
> >> (define-inline cconv--var-classification (binder form)
> >> (inline-quote
> >> (cdr (assoc ,(cons (inline-const-val binder)
> >> (inline-const-val form))
> >> cconv-var-classification))))
> >
> > Don't you need something to add a quote to the cons cell when "binder"
> > or "form" are not constant?
>
> Oh, you're right.
>
> >> but here as well, this optimization would never apply because those args
> >> are never literal constants. Worse: the failure of `inline-const-val`
> >> would cause the whole inlining to fail :-(
> > Could inline--do-quote catch the throw?
>
> It could, but it doesn't (and it would be an incompatible change).
As far as I can tell, the only code that makes use of inline-const-val
is cl-typep, so the impact of any incompatibility should be (famous
last words) controllable. Is the issue figuring out how to define
inline-letevals so that inline-const-val would be able to "see
through" it when the parameter is constant but be bound by it when it
is not constant?
> > The byte-opt.el code from v28.2.50 says it's because the third
> > argument may be an impure function:
> > ;; `assoc' and `assoc-default' are excluded since they are
> > ;; impure if the test function is (consider `string-match').
> > I'm not sure why the possibility of signaling an error alone would be
> > disqualifying. For example, (+ 5 's) signals an error.
>
> Oh, you're right, sorry. So the problem is if the test function is
> constant but not pure.
>
> > Also, I don't get why logand isn't considered a pure function
>
> What makes you think it's not?
>
Faulty memory - I was thinking of lsh as mentioned in this comment
from byte-opt.el:
;; Pure functions are side-effect free functions whose values depend
;; only on their arguments, not on the platform. For these functions,
;; calls with constant arguments can be evaluated at compile time.
;; For example, ash is pure since its results are machine-independent,
;; whereas lsh is not pure because (lsh -1 -1)'s value depends on the
;; fixnum range.
> > How important is it to be able to run byte-code generated by
> > a 32-bit emacs in a 64-bit emacs (or vice-versa)?
>
> The Emacs tarball comes with all the `.elc` files, so it's important
> that `.elc` files be portable across architectures.
Interesting restriction.
Lynn
next prev parent reply other threads:[~2023-05-21 12:47 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM=F=bCAWxsPPT21_KJos7OKiphnKe5HqK4-UPVCkmqhX9okqA@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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).