Re: byte-opt.el addition - optimize list of compile-time constants

[Zack Weinberg <zack@codesourcery.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (disassemble 
>>   (lambda nil 
>>     `(:a 1 :b 2 
>>       :c ,#'(lambda nil (when (eq (following-char) ?\n) (forward-char 1))))))
> [...]
>> second place, byte-optimize-pure-func is called, but the optimization
>> fails because a (function ...) form appears inside the arguments to
>> list, which does not count as byte-compile-constp.  This is the other
>
> Hmm... we should probably update byte-compile-constp to accept
> (function ...) just like it accepts (quote ...).

Yes, that sounds like a good move.

>> problem I mentioned earlier - at the point at which the
>> 'byte-optimizer function for list is called, the inner function has
>> not yet been compiled, contrary to the general principle that the
>> byte optimizer operates depth-first.
>
> The "byte-optimizer" has two phases: one done before
> byte-compilation and one after.  The byte-optimize-pure-func is done
> before.

Right.  I was referring to the source optimizer.  Whatever the
consequence, this means the best the source optimizer can do is
convert my `(...) form to a '(...) form, and the inner lambda won't
get compiled.

I suppose I'm trying to fix the bug in the wrong place.  Really, what
I want is for the byte compiler to look inside complicated '(...)
forms for embedded lambda expressions, and compile them.  I think it's
byte-compile-quote that would be responsible for doing that?

> As for your particular problem, there's an easier solution:
>
>     (defun foo-aux nil (when (eq (following-char) ?\n) (forward-char 1))
>     ...
>     (lambda nil
>       '(:a 1 :b 2 :c foo-aux))

This is what I've done for the time being, but I consider it somewhat
infelicitous, which is why i'm flailing around trying to improve the
byte compiler.

zw