GNU bug report logs - #52063
28.0.60; Confusing presentation of lambda

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 52063 <at> debbugs.gnu.org
Subject: bug#52063: 28.0.60; Confusing presentation of lambda
Date: Wed, 24 Nov 2021 15:08:38 -0500

>> No, but in 99% of the cases you won't actually *see* a function value
>> (unless you specifically go looking for it, e.g. with `symbol-function`).
> We also have gobs of variables that are not hooks, which accept
> function values.

Indeed, tho I think there are a few more such hooks and at least I have
looked at hook values a lot more often than I have looked at
<foo>-function values.

> And we also have menu items and mode-line constructs
> that sometimes use anonymous functions.

I think it's very rare for a user to look at those objects.

> And timer functions.

I can't remember the last time I looked at such a value.  And given the
extra info attached to it, it's not very legible so I don't think people
are affected very much by a change in the actual function
representation there.

> And process filter and sentinel functions.

Same here: you will often set them, but very rarely will you actually
look at their value.

> And that's just 5 sec of thinking where one could meet them.

Indeed, there are many more places.

>> So you'll only get a value of the form (lambda ARGS . BODY) if you use
>> the dynamically scoped dialect of ELisp (or if you manually create such
>> a list, e.g. with '(lambda ...) or `(lambda ...) or (list 'lambda ...),
>> etc...).
>
> 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...

> So why do we emit those warnings for Lisp code evaluated from a file
> that doesn't have lexical-binding setting in it?

Those warnings predate the introduction of lexical scoping, indeed.

They're mostly there so you don't mistakenly write code which the
byte-compiler can't compile (and which `flymake` can't analyze to give
you further feedback about issues in that code).

It's all about the difference between code and data ;-)


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.