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

[Zack Weinberg <zack@codesourcery.com>]

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

>> I dug through the byte-compiler a bit and determined that it makes no
>> attempt whatsoever to optimize (list ...) expressions.  So I wrote a
>
> The reason for this is that (eq (list 1) (list 1)) returns nil.
> So the optimization which replaces (list 1) with '(1) can change the
> behavior of the code.

I was going to suggest that (list 1 2 3) or longer could be replaced
with (copy-list '(1 2 3)) in that case.  Three entries is the point at
which the generated bytecode starts being shorter for copy-list.
However, I see that copy-list is not a primitive, nor even a standard
function, but a CL function, so that won't fly.

> PS: Note that `concat' has the same problem, and yet (concat "foo" "bar")
>     is byte-optimized to "foobar".  The reason for the difference is that
>     it so happens that such differences matter much less often for strings,
>     and also that the optimzation has been used for such a long time that it
>     can be considered as part of the semantics of `concat'.

I seriously wonder how much would break if this optimization were
implemented for 'list'.  My suspicion is that people don't commonly
apply 'eq' to lists in the first place.

zw