Re: Codifying some aspects of Elisp code style and improving pretty printer

[Robert Pluim]

>>>>> On Fri, 01 Oct 2021 11:26:51 -0400, Stefan Monnier 
>>>>> <monnier@iro.umontreal.ca> said:

    >> Apropos, I believe the current recommendation is to do
    >> (mapconcat #'identity seqs " ")
    >> rather than
    >> (mapconcat 'identity seqs " ")
    >> ie function-quoting the argument to mapconcat, apply, mapc etc, but

    Stefan> Indeed, the main benefit being that the byte-compiler can warn you 
if
    Stefan> the function is not known to be defined (typically because of a 
typo or
    Stefan> a missing `require`).

    Stefan> A side benefit is that it "does the right thing" for `cl-flet` and 
friends.

    >> 1. The elisp manual doesnʼt say that in (info "(elisp) Mapping 
Functions")

    Stefan> Not sure that'd be the best place, but we should probably adjust the
    Stefan> manual to encourage the use of #' to quote function names,

All the examples there use 'quote', and the discussion of 'quote' vs
'function' is in (info "(elisp) Anonymous Functions"). People who've
just gone 'i mapc' in the elisp manual have no reason to read that
second node. Patch below

    >> 2. Emacs' code itself doesnʼt do that consistently

    Stefan> The difference is sufficiently unimportant that I don't see a need 
to
    Stefan> try and make it consistent in this respect.  E.g. I do change 'foo 
to
    Stefan> #'foo quite often, but only as part of other changes.

OK. Thatʼs ~900 spurious changes we can avoid making :-)

    >> (and we have the odd #'(lambda ...) as well

    Stefan> I don't see anything wrong with #'(lambda...)
    Stefan> [ I personally prefer to skip the #' to make the code (marginally)
    Stefan>   shorter, but it's purely a matter of taste and I usually try and
    Stefan>   refrain from making this change in existing code unless it helps 
make
    Stefan>   the code fit into 80 columns.  ]

If dislike it, because I view lambda as self-quoting, but as you say
thatʼs a personal preference (although "(elisp) Anonymous Functions"
kind of tells you not to quote lambda's).

    >> 3. The byte compiler doesnʼt warn about it.

    Stefan> Mine does ;-)
    Stefan> But I wouldn't want to enable such a warning by default (or at 
least it
    Stefan> should be mess a bit less eager than it is, because of the 
occasional false
    Stefan> positives).

Iʼve not seen any false positives from mine, but I suspect itʼs less
sophisticated than yours :-)

    >> I believe it helps the byte-compiler generate better code, but donʼt
    >> know what the actual effect is.

    Stefan> It has no effect on the generated code.

OK, so no code change, but how about:

diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index c856557c3c..4416b39f09 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -890,6 +890,33 @@ Mapping Functions
 over a char-table in a way that deals properly with its sparse nature,
 use the function @code{map-char-table} (@pxref{Char-Tables}).
 
+  All the mapping functions described here take a function as their
+first argument, which can be specified in different ways:
+
+@itemize
+@item An anonymous lambda
+
+@example
+(mapcar (lambda (x) (x)) ....)
+@end example
+
+@item A function-quoted symbol
+
+@example
+(mapcar #'identity ....)
+@end example
+
+@item An quoted symbol
+
+@example
+(mapcar 'car ....)
+@end example
+@end itemize
+
+The last two are equivalent, except that function-quoting can help the
+byte-compiler warn if the function being called is
+undefined.  @xref{Anonymous Functions} for more information.
+
 @defun mapcar function sequence
 @anchor{Definition of mapcar}
 @code{mapcar} applies @var{function} to each element of @var{sequence}