bug#52063: 28.0.60; Confusing presentation of lambda

[Stefan Monnier]

>> > So I guess the warning about quoting lambdas with ' instead of #' is
>> > actually misleading people into getting these closures instead of the
>> > lambdas they might expect?
>> 
>> A value (lambda ...) is fundamentally a list.  The rest of the system
>> (e.g. the byte-compiler, flymake, ...) can't know if you intend to use
>> this list as a function, so it can't really look inside to compile its
>> body, warn you about typos in its body, or uses of obsolete
>> vars/functions, etc...
>
> I'm talking about evaluation, not about byte-compilation.
> This happened when Emacs was processing my init file.

I'm tlking neither specifically about evaluation nor compilation, I'm
just talking about the meaning of

    '(lambda ...)

which prevents our tools from looking at the code inside of it because
those tools can't tell whether it's supposed to contain source code or
just arbitrary data.

>> It's all about the difference between code and data ;-)
> What difference?  I always thought that in Emacs Lisp there's no such
> difference.

I think saying that "code is data" is misunderstood.  All it means is
that code is exposed as a kind of data, e.g. via macros.

But obviously not every piece of data is a valid and usable piece of code.
And when ELisp knows that a specific piece of data is actually a piece
of code, it can take the liberty to manipulate it accordingly under the
assumption that it's "somewhat opaque" and that the only thing we're
going to do with it is evaluate/run it rather than manipulate it with,
say, `car/cdr`.
E.g. when we load a .el file containing:

    (defun foo (xs) (dolist (x xs) (when x (message "%s" x))))

the `symbol-function` cell of `foo` will not contain

    (dolist (x xs) (when x (message "%s" x)))

> Does lexical-binding change that as well?

It makes the difference a bit bigger.


        Stefan