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

[Zack Weinberg <zack@codesourcery.com>]

Miles Bader <snogglethorpe@gmail.com> writes:

>> >> I thought the whole point of (function ...) was to assert that the
>> >> lambda expression it contains *will* be used by execution.
>> >
>> > Yes, but that only applies if it occurs in an evaluable context.
>> > Anyplace else, all bets are off.
>> 
>> That strikes me as just plain silly.  What's the point of a hint if it
>> doesn't always mean what it means?
>
> If there's a random arbitrary list constant in some code, how on earth
> is the compiler supposed to tell what the intended meaning of
> sub-components of the list are?!?

By reference to the language definition.  That's really what we're
quibbling about here - I'm saying the language should be defined such
that (function (lambda ...)) should indicate a function constant even
if arbitrarily nested within a (quote ...) form, you're saying it
shouldn't.

In evidence for my position I would like to point out that it is silly
for '(1 2 3 #'(lambda ...) 4 5 6) to mean something different than
(list 1 2 3 #'(lambda ...) 4 5 6), and the byte compiler compiles the
embedded lambda in the second case, so logically it ought to in the
first case as well.

Also, in Common Lisp the situation is clearly that the compiler _is_
entitled to compile (function ...) wherever it finds it - Emacs Lisp
is not the same thing, of course, but I see no reason for divergence
here.

zw