On Fri, Jan 08, 2021 at 01:38:24PM +0100, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
> 
> > I think Stefan explained that pretty well in this thread:
> > dotimes is implemented as a macro (the alternative would be
> > to special-case it) which introduces a let-binding
> 
> But surely this happens elsewhere as well?

Possibly, yes.

> > to the counting index... which is used in the result part,
> > unless it's not used, which then causes the byte compiler to
> > issue the warning.
> 
> But the warning isn't specifically introduced for this
> situation, is it?

No, it's not.

>                   Because then it could just say that, instead
> of the confusing wasn't used thing.


> 
> But if it isn't, then why is it triggered by this at all and
> how can it be so specific to even act upon a certain part of
> the construct?
> 
> > Fixing that would take
> >
> >  (a) special-casing dotimes somehow. For maintaniability
> >      reasons probably out of the question
> 
> No.
> 
> >  (b) making the macro expander for dotimes smarter, to
> >     skip introducing the let-binding.
> 
> No.
> 
> >  (c) (that seems Stefan's favourite, and I tend to trust him
> >      blindly in those things) discourage the three argument
> >      use of dotimes, since it's not that idiomatic in Elisp
> >      anyway (those idioms are more Common Lisp-y).
> 
> Ha :) Well, whatever.
> 
> > Makes more sense now?
> 
> No! Again, this is a problem with the byte compiler.
> So rather, fixing it would take

No. It's a problem somewhere between the macro expander
and the byte compiler. Or with the idiom's design itself,
depending on how you squint.

>    (d) fixing the byte compiler

No. The byte compiler can't know. Fixing the macro expander
perhaps. Or introducing a special communication channel
between both ("Hey, byte compiler: this is the macro
expander talking. This funny variable "i2975" you are seeing
has been introduced by me behind the user's back, because
she insists on using that quaint and curious three-args
dotimes macro. So don't warn if that variable is unused.
But then, perhaps it being unused isn't what's intended,
so please -- uh -- do whatever"

Have you had a look at a dotimes macro expansion?

Try:

  (macroexpand
    '(dotimes (i 10 0)
        (message "%d\n" i)))

There you'll find that last thingy:

  (let ((i --dotimes-counter--))
    0)

(i.e. the RESULT arg in dotimes is there, but it's NOT using
the count variable. There it is! An unused variable! And the
byte compiler wasn't involved yet at all. When it sees that,
it'll balk at the unused i. Fixing the byte compiler seems
like the least attractive variant to me.

Fixing the macro definition is a bit more attractive (e.g.
it could try to decide whether RESULT depends on i and
not generate that let-binding if not), but I can't decide
right now whether that involves the halting problem or not.

Here's a challenge for you :) (I guess Stefan would accept
a patch /if/ it makes sense and isn't too painful otherwise).

Fixing the usage (or the user expectation) seems to me like
the most attractive way out, at the moment :)

Cheers
 - t