Re: How to avoid compiler warning `unused lexical variable' for `dolist' or `dotimes'?

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2021-01-08 08:14]:
> > To me that means that I need to use workaround because `dotimes' does
> > not work well as described in docstring. I need to remember something
> > that is nowhere documented.
> 
> In which way doesn't it work as documented?
> The warning is just that: a warning.  It doesn't affect the actual behavior.
> 
> > Either compiler warning is wrong, or docstring is wrong.  One of those
> > shall be improved.
> 
> AFAIK both are right: you put into the 3rd arg an expression that is
> evaluated in a context where a new variable `var` has been added for you
> but you don't make use of that variable.  This fact doesn't prevent the
> code from being valid and executed correctly, but it is suspicious so it
> deserves a warning.

I think there is some mistake here.

I have placed third value where I use the third value, but compiler warning is 
complaining about first one.

For example in (dolist (n 10 return) ...) compiler would warn about `n' and not 
about `return'.

If it complains about `return' when not used, that would be just fine
for me, good warning and logical. But I do not speak of that case.

Complete example, in file new.el:

;; -*- lexical-binding: t; -*-

(defun my-fun ()
  (let ((list '()))
    (dotimes (n 10 list)
      (push n list))))

Compiling file /home/data1/protected/new.el at Fri Jan  8 08:34:04 2021
new.el:3:1: Warning: Unused lexical variable n

So that is what I speak about. The `n' variable is assigned right
there similar to `let' so I think that maybe macro shall be improved.

> A warning is emitted when the code is valid but where we think it's
> useful to bring the attention to something of which the programmer may
> not be aware.

I wish to make all programs warning free. If I need to get aware of
some function than such warning should be placed in the function
documentation. For example, what I was thinking first is that `n' from
above example should be somehow already declared. The docstring of
`dotimes' should tell me something about that. But we have here hidden
anti-features that are not documented, known only to developers and
available only in mailing list messages.

Sorry I cannot understand the macro expansion at this moment, but
thank you. Maybe somebody else understands it.

> We occasionally also use those warnings to nudge programmers toward
> a particular programming style, i.e. with a conscious decision to make
> people change their style, which makes it yet more likely that some
> people will disagree (at least at first, until they get used to the new
> style).  E.g. in early Emacs it was a lot more common to find packages
> which relied on non-trivial ways uses of dynamic scoping and undeclared
> global vars.  After adding warnings for uses of "free variables" the
> style changed over the years, making it possible in Emacs-24 to
> introduce lexical scoping such that the vast majority of the code works
> unchanged when `lexical-binding` is activated.

That is great. 

Only it is not relevant to macro or function that is documented to
work, but then again it gives warnings for `n' and not for `return' as
in above example. 

I am surprised.

For me personally I will stick to the built-in functions such as
`while' and mapping functions and will rather try to avoid `dotimes'
and `dolist', unless the error is corrected.

Jean