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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

> I suppose I'm trying to fix the bug in the wrong place.

I don't think so.  At least if you want to solve it in the byte-compiler,
doing it at the source-level is probably not a bad idea.

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

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

What's infelicitous about it?


        Stefan