Re: inline function expansion

[Stefan Monnier]

> 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.

> 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))))

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 :-(

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).

> 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.


        Stefan