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

[Zack Weinberg]

Stefan Monnier <address@hidden> writes:

>>>> 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.
>
> No.  If you change byte-compile-constp to recognize `function', together
> with marking the list/cons/append primitives as pure, it should work.

How can it?  The best that the source optimizer can do is turn
`(... ,#'(lambda ...) ...) into '(... #'(lambda ...) ...).  This
happens *before* anything goes looking for nested functions to
compile.  And I already know that if I write '(... #'(lambda ...) ...), 
the function does not get compiled.

>> 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?
>
> That's dangerous because there can be a (lambda ...) form without
> it actually being meant to be byte-compiled.

which is what (function ...) is for, right?  I am quite confused by
what the manual says about function vs. bare lambda expressions.

>>> (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.
>
> What's infelicitous about it?

More reading, less everything-in-one-place-ness.  Basically the same
thing that's infelicitous about writing a separate defun for a simple
mapcar callback that will only be used in one place.

zw