Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Sun, Apr 19, 2020 at 2:45 AM Stefan Kangas <stefankangas@gmail.com>
wrote:
>
> branch: master
> commit 8f0f8516501e64348994334cdab8b211f1cfd731
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     * lisp/autoarg.el: Use lexical binding.

Compiling file [...]/trunk/lisp/autoarg.el at Sun Apr 19 08:16:38 2020
autoarg.el:61:1: Warning: Unused lexical variable ‘i’

[-- Attachment #2: Type: text/html, Size: 682 bytes --]

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Kangas]

Juanma Barranquero <lekktu@gmail.com> writes:

> >     * lisp/autoarg.el: Use lexical binding.
>
> Compiling file [...]/trunk/lisp/autoarg.el at Sun Apr 19 08:16:38 2020
> autoarg.el:61:1: Warning: Unused lexical variable ‘i’

Thanks, should be fixed now.

I don't think I understand the original warning though.  This
minimized code example gives me "Unused lexical variable 'i'" when
byte-compiled:

(let (alist)
  (dotimes (i 10 alist)
    (push i alist)))

Best regards,
Stefan Kangas

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Stefan Kangas <stefankangas@gmail.com> writes:

> I don't think I understand the original warning though.  This
> minimized code example gives me "Unused lexical variable 'i'" when
> byte-compiled:
>
> (let (alist)
>   (dotimes (i 10 alist)
>     (push i alist)))

See the FIXME in the implementation.  This exact issue had been
discussed the last time not long ago.

Michael.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Noam Postavsky]

On Mon, 20 Apr 2020 at 01:35, Michael Heerdegen
<michael_heerdegen@web.de> wrote:
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > I don't think I understand the original warning though.  This
> > minimized code example gives me "Unused lexical variable 'i'" when
> > byte-compiled:
> >
> > (let (alist)
> >   (dotimes (i 10 alist)
> >     (push i alist)))
>
> See the FIXME in the implementation.  This exact issue had been
> discussed the last time not long ago.

Also https://debbugs.gnu.org/39919

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Monnier]

> I don't think I understand the original warning though.  This
> minimized code example gives me "Unused lexical variable 'i'" when
> byte-compiled:
>
> (let (alist)
>   (dotimes (i 10 alist)
>     (push i alist)))

It's unused in the expression `alist`.  If you don't use `i` there, then
you should do:

    (let (alist)
      (dotimes (i 10)
        (push i alist))
      alist)


-- Stefan

RE: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Drew Adams]

> > I don't think I understand the original warning though.

Same here.

> > This minimized code example gives me "Unused lexical
> > variable 'i'" when byte-compiled:
> >
> > (let (alist)
> >   (dotimes (i 10 alist) (push i alist)))
> 
> It's unused in the expression `alist`.

So?  (defun foo (a) (message "%s" a) 42) doesn't use
`a' in the value returned.  We don't warn about that,
do we?

> If you don't use `i` there, then you should do:
> (let (alist)
>   (dotimes (i 10) (push i alist))
>   alist)

Doesn't seem right to have such a distinction.  Is
this just an implementation artifact (essentially a
bug), or is there a good reason for the warning in
the first case (and not in the second)?

FWIW, all that Common Lisp says about its `dotimes'
in this regard is this:

"At the time result-form is processed, VAR is bound
to the number of times the body was executed."

Why should we warn, if the result form doesn't use
the variable?

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Monnier]

>> If you don't use `i` there, then you should do:
>> (let (alist)
>>   (dotimes (i 10) (push i alist))
>>   alist)
>
> Doesn't seem right to have such a distinction.

It does seem right to me (probably because I find hiding the return
value inside the first arg to `dotimes` to be a bad practice).

> Is this just an implementation artifact

It's mostly an implementation artifact, but one which I think happens to
be good.


        Stefan

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > Is this just an implementation artifact
>
> It's mostly an implementation artifact, but one which I think happens
> to be good.

The bad thing is that most people don't understand why that happens and
are just confused and wasting time.

Since RESULT is deprecated anyway, and there were no strong opinions
against that, I would like to turn that warning into a warning that
always happens when you use RESULT saying "warning: argument RESULT in
dotimes is deprecated" or so.

The only other reasonable alternative I see is to fix the warning.  What
we now have shouldn't be the end state.

FWIW, personally I never liked that RESULT argument, I find it odd no
matter if it depends on the iteration var or not.

Michael.

Strange compiler warning in `dotimes' (was: master 8f0f851: * lisp/autoarg.el: Use lexical binding.)

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The bad thing is that most people don't understand why that happens
> and are just confused and wasting time.

I have merged the recent Bug#39919 "Incorrect byte-compiler warning"
with the respective bugs from the past (hope I did it right) - the
merged report is probably a better place to continue discussing than
here.

Michael.

RE: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Drew Adams]

> Since RESULT is deprecated anyway, and there were no strong opinions
> against that, I would like to turn that warning into a warning that
> always happens when you use RESULT saying "warning: argument RESULT in
> dotimes is deprecated" or so.

Why was RESULT deprecated?

RESULT is good enough for Common Lisp.  Why isn't
it good enough for Elisp?  Just curious.

http://clhs.lisp.se/Body/m_dotime.htm

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Why was RESULT deprecated?
>
> RESULT is good enough for Common Lisp.  Why isn't
> it good enough for Elisp?  Just curious.

See the discussion in Bug#16206.

Michael.

RE: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Drew Adams]

> > Why was RESULT deprecated?
> >
> > RESULT is good enough for Common Lisp.  Why isn't
> > it good enough for Elisp?  Just curious.
> 
> See the discussion in Bug#16206.

I saw it.  I still have the same question.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > > RESULT is good enough for Common Lisp.  Why isn't
> > > it good enough for Elisp?  Just curious.
> >
> > See the discussion in Bug#16206.
>
> I saw it.  I still have the same question.

Some people argued that RESULT is not so useful, and it's position in
the syntax is strange, and seems nobody really found this totally wrong.

BTW, in the discussion in said bug report we now found the idea to
always warn about using the RESULT argument in subr.el's dotimes (in
order to remove it later) and fix the warning in cl-dotimes.

Michael.

RE: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Drew Adams]

> Some people argued that RESULT is not so useful, and it's position in
> the syntax is strange, and seems nobody really found this totally
> wrong.
> 
> BTW, in the discussion in said bug report we now found the idea to
> always warn about using the RESULT argument in subr.el's dotimes (in
> order to remove it later) and fix the warning in cl-dotimes.

Perhaps the difference in usefulness has to
do with other differences between dotimes
and cl-dotimes.  Perhaps the RETURN arg is
more useful in combination with go tags,
for instance.  Dunno.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Vladimir Sedach]

Drew Adams <drew.adams@oracle.com> writes:
> Why was RESULT deprecated?

That is indeed bizarre. Why break existing Elisp code? David
Touretzky provides lots of examples of how to use RESULT with DOTIMES
and DOLIST in _Common Lisp: A Gentle Introduction_. Conceptually,
RESULT is a neat way to have the DOLIST/DOTIMES/DO expression
evaluate to a useful value, instead of always being nil valued.
Deprecating RESULT makes it harder to port Common Lisp code to Elisp.

Those are four good arguments for keeping it.

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Monnier]

> RESULT is good enough for Common Lisp.  Why isn't
> it good enough for Elisp?  Just curious.

I think the question makes no sense.  Noone said it's not "good enough
for Elisp" because noone is suggesting to make it better.


        Stefan

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Vladimir Sedach <vas@oneofus.la> writes:

> Touretzky provides lots of examples of how to use RESULT with DOTIMES
> and DOLIST in _Common Lisp: A Gentle Introduction_. Conceptually,
> RESULT is a neat way to have the DOLIST/DOTIMES/DO expression

Some of us don't find it neat.

Are there examples in that book that aren't easily rewritten without the
RESULT arg, and/or the skeptical people here would say ah! that's really
neat and elegant?

Do you often use it, personally?

> Deprecating RESULT makes it harder to port Common Lisp code to Elisp.

As I said, I would make the cl- version support it.  I don't expect that
code is very frequently ported from Common Lisp to Elisp.  But AFAIR
scheme also has RESULT in its `do', so people coming from other Lisps
might miss it.  I don't know any Lisp programmers, I can't say.

Michael.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Monnier]

> Conceptually, RESULT is a neat way to have the DOLIST/DOTIMES/DO
> expression evaluate to a useful value,

It's not.  Putting the return value right after (wrapping the two in
a `progn` if needed) is a much neater solution, which is also visually
much better at clarifying what is returned.

The only potential usefulness of the RETURN part is to get access to the
"after-last" value of the iteration variable (which is the only
concrete difference between using RESULT or placing the result as
a separate expression after the iteration).

> Deprecating RESULT makes it harder to port Common Lisp code to Elisp.

I have tried to port a few Common Lisp codes to Elisp, and this kind of
syntactic rewrite is so trivial to handle (and the dotimes/dolist macros
could even tell you how to do them) that it doesn't even register in
comparison to the much harder work of dealing with library differences,
packages, reader macros, ...


        Stefan

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Stefan Monnier]

> But AFAIR scheme also has RESULT in its `do', so people coming from
> other Lisps might miss it.

This one is quite different because it has access to the final value
of all the loop variables.  So while it is occasionally possible to move
the "RESULT" expression to after the `do` loop, it's often not an option
because it needs to access some of the loop variables.

For `dolist` this can *never* happen because the only loop variable is
known to always contain nil at that point.

For `dotimes` this can very occasionally happen, tho you can always work
around it with a simple rewrite.


        Stefan

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Noam Postavsky]

On Tue, 28 Apr 2020 at 22:35, Vladimir Sedach <vas@oneofus.la> wrote:

> Drew Adams <drew.adams@oracle.com> writes:
> > Why was RESULT deprecated?
>
> That is indeed bizarre. Why break existing Elisp code? David
> Touretzky provides lots of examples of how to use RESULT with DOTIMES
> and DOLIST in _Common Lisp: A Gentle Introduction_.

I think it's useful to look at a couple of concrete examples from
there. I found it at <https://www.cs.cmu.edu/~dst/LispBook/book.pdf>.
There is this kind of usage (page 345):

    (defun it-intersection (x y)
      (let ((result-set nil))
        (dolist (element x result-set)
          (when (member element y)
            (push element result-set)))))

The argument for deprecating the RESULT param is mainly because code
like this is (arguably) clearer when written

    (defun it-intersection (x y)
      (let ((result-set nil))
        (dolist (element x)
          (when (member element y)
            (push element result-set)))
        result-set))

Because it's easier to quickly pick out what the return value is.
Obviously it's a matter of taste to some degree though.

There's another kind of usage that isn't as easily replaced (page 343):

    (defun check-all-odd (list-of-numbers)
      (dolist (e list-of-numbers t)
        (format t "~&Checking ~S..." e)
        (if (not (oddp e)) (return nil))))

But this relies on dolist establishing a block that be used with
return. So in elisp, this should be done with cl-dolist which I
believe everyone agrees will always support the RESULT argument.

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Vladimir Sedach]

Michael Heerdegen <michael_heerdegen@web.de> writes:
> I don't know any Lisp programmers, I can't say.

Well, you are replying to one. I program regularly in Common Lisp and
Elisp, and occasionally in Scheme. Most of the Elisp code I write is
"ported" from Common Lisp, because that is the Lisp dialect I am most
familiar with, and "think" in. Obviously I make occasional use
RESULTS in DOLIST/DOTIMES/DO/DO*, otherwise I would not have an
opinion about it.

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It would take a strong reason justify introducing an incompatibility
which breaks code.  The reasons people have stated here might be enough
reason not to introduce the RESULT argument, but they are not enough
reason to remove it.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: master 8f0f851: * lisp/autoarg.el: Use lexical binding.

[Michael Heerdegen]

Richard Stallman <rms@gnu.org> writes:

> It would take a strong reason justify introducing an incompatibility
> which breaks code.  The reasons people have stated here might be
> enough reason not to introduce the RESULT argument, but they are not
> enough reason to remove it.

And just the fact of how often the question about the warning popped up
in the last weeks shows that quite some people want to use the RESULT
argument.

So I see no alternative but to fix the warning and undeprecate the
RESULT argument.  I will do this shortly if there are no objections.

Michael.