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

[Zack Weinberg <zack@codesourcery.com>]

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

> Note that the expression
>
>      (list 1 2 (function (lambda () (with-current-buffer))))
>
> can be rejected by the compiler (not enough arguments to the
> with-current-buffer macro) whereas
>
>      '(1 2 (function (lambda () (with-current-buffer))))
>
> can't because it's just a quoted constant which just happens to look like
> invalid code.

I'd say that the compiler can and should reject your second example
precisely so that the equivalence of the two forms can be preserved.

Miles Bader <snogglethorpe@gmail.com> writes:
>> Also, in Common Lisp the situation is clearly that the compiler _is_
>> entitled to compile (function ...) wherever it finds it
>
> Can you provide a reference for this?  Given that it's quite
> dangerous, I'm skeptical of this claim.

I was going by CLTL/1, which says "The value of function is *always*
the functional interpretation of [its argument]" (emphasis mine).
That's a little ambiguous (although, as standardese goes, pretty damn
clear (my brain may have been warped by the C standard's heinous
ambiguities)).

The most recent edition of the ANSI Common Lisp spec that I can find
online
[http://www.lispworks.com/reference/HyperSpec/Front/Contents.htm] says
basically the same thing, but goes on to observe that function objects
may not appear in quoted literals which are to be processed by
compile-file.  I'm not really sure what the implications are.  See
<http://www.lispworks.com/reference/HyperSpec/Issues/iss082_w.htm>.

> Note that a possibly safer alternative would be to have the #'
> reader macro expand into something less ambiguous during compilation
> (e.g., a special non-interned symbol), which the byte-compiler could
> then safely interpret inside of constants.  This may cause grief for
> somebody that uses #' in a non-traditional way, and _expects_ to see
> (function (lambda ...)), but that may be an acceptable price.

I don't think this is any better than saying that function always
means function, even if not evalled.

zw