[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: byte-opt.el addition - optimize list of compile-time constants
From: |
Zack Weinberg |
Subject: |
Re: byte-opt.el addition - optimize list of compile-time constants |
Date: |
Wed, 08 Dec 2004 18:33:44 -0800 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) |
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
- Re: byte-opt.el addition - optimize list of compile-time constants, (continued)
- Re: byte-opt.el addition - optimize list of compile-time constants, Stefan Monnier, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Stefan Monnier, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Stefan Monnier, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants,
Zack Weinberg <=
- Re: byte-opt.el addition - optimize list of compile-time constants, Miles Bader, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Miles Bader, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Miles Bader, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/08
- Re: byte-opt.el addition - optimize list of compile-time constants, Stefan Monnier, 2004/12/09
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/09
- Re: byte-opt.el addition - optimize list of compile-time constants, Miles Bader, 2004/12/09
- Re: byte-opt.el addition - optimize list of compile-time constants, Zack Weinberg, 2004/12/09