Re: inline function expansion

[Stefan Monnier]

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

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

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

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?

    ELISP> (symbol-plist 'logand)
    (gv-expander #f(compiled-function
                (do place &rest masks)
                #<bytecode -0xc7679d4528b2a2a>)
              side-effect-free t pure t)
    
    ELISP>

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


        Stefan