GNU bug report logs -
#52063
28.0.60; Confusing presentation of lambda
Previous Next
Full log
Message #74 received at 52063 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org, 52063 <at> debbugs.gnu.org
> Date: Wed, 24 Nov 2021 15:08:38 -0500
>
> > 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.
I look at the values to make sure they are what I expect. It's normal
in Emacs to do that, isn't it?
> > 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.
> It's all about the difference between code and data ;-)
What difference? I always thought that in Emacs Lisp there's no such
difference. Does lexical-binding change that as well?
This bug report was last modified 3 years and 255 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.