Re: inline function expansion

[Lynn Winebarger]

On Fri, May 19, 2023 at 9:31 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > After some more investigation, the only other code I've seen that uses
> > define-inline to do more than defsubst would (as I understand it) is
> > in gnus-sum.el:
> > (define-inline gnus-summary-article-header (&optional number)
> >   "Return the header of article NUMBER."
> >   (inline-quote
> >    (gnus-data-header (gnus-data-find
> >       ,(or number
> >                            (inline-quote (gnus-summary-article-number)))))))
> > And I believe that occurence of "number" should be
> > "(inline-constant-val number)".
>
> 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.
>
> > One example where there could be a use of define-inline's additional
> > functionality is in:
> > (define-inline cconv--var-classification (binder form)
> >   (inline-quote
> >    (cdr (assoc (cons ,binder ,form) cconv-var-classification))))
> >
> > That could be changed to
> > (define-inline cconv--var-classification (binder form)
> >   (inline-quote
> >    (cdr (assoc ,(inline-quote ,(cons (inline-const-val binder)
> > (inline-const-val form))_ cconv-var-classification))))
>
> I think you can simplify that to:
>
>     (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?
>
> 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?

> To support this kind of optimization we'd need to add specific support
> for it to `define-inline`.
>
> > Automating the first one involves identifying the maximal constant
> > expression containing each potentially constant parameter, which is
> > hard in general.  But if we restrict the language handled by the
> > inliner, it might be doable.  For example, if we could assume no
> > macros implicitly bind any identifiers already in use, and parameters
> > marked with &const as a guarantee  that the result of the function
> > does not vary based on state associated with them, maybe that would be
> > enough to determine non-trivial subexpressions pure subexpressions
> > above rather than forcing the user to identify them explicitly by
> > unquoting.
>
> The driving principle behind `define-inline` is to not do any analysis
> and leave that responsability in the hands of the users of
> `define-inline` :-)
>
> So we could/should add some special annotation like (inline-precompute
> <FOO>) which treats <FOO> as an expression that builds a value and
> precomputes it if all the `,<EXP>` that appear in it are
> `inline-const-p`.
>
> > For the second,  I'm thinking that what the programmer wants to
> > express is that if the "type" parameter is constant, then reducing all
> > forms with pure operators with respect to type is a "pure" macro in
> > the sense that it will always produce the same expression, and that
> > expression has no occurrences of "type".
>
> Note that in the case of `cl-typep` the expansion may fail to fully
> eliminate the "type" parameter, IIRC (i.e. it manages to inline/unroll
> part of the recursion but not all of it because some part of the type is
> not statically known or too complex).

I don't know what "too complex" would entail, but if it's not
statically known then the type arg isn't really a constant so it's not
really a failure.

>
> > Then assoc is pure because when all three arguments are constant
> > (i.e. the test function is pure), then the value is constant.
>
> IIRC the reason it's not "pure" (for some definition of "pure") is
> because it can signal an error.

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.

Also, I don't get why logand isn't considered a pure function - 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)?  I could see it making sense
historically, but is it still a useful property of byte-code?