unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Gauthier Östervall" <gauthier@ostervall.se>
To: Stefan Monnier <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
Subject: Re: sending function arguments to recursive function calls
Date: Fri, 17 May 2013 14:20:02 +0200	[thread overview]
Message-ID: <CAM8gEgjSxngm69rEm4AyQm9=SuPtvucwc3p2VfbJ3bAs8EXPRg@mail.gmail.com> (raw)
In-Reply-To: <jwvr4hbvsp1.fsf-monnier+INBOX@gnu.org>

On Mon, May 13, 2013 at 4:55 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> That's the question that the byte-compiler can't answer: maybe they
> really weren't used (so you can remove them), or maybe they were used
> elsewhere via dynamic scoping (in which case you need to add a (defvar
> <var>) to force the use of dynamic scoping for this variable).

All the variables that the byte-compiler complained about were defined
in the first parameter of a let or a let* expression.

My understanding of let and let* is that the first parameter defines
local variables to be used in the second parameter (or later in the
first parameter in the case of let*).

The unused variables I had to remove were not referenced in the last
parameter of the let or let* (nor later in the first parameter of
let*), so I assumed they were not used anywhere.

Is there a way that such variables may be used elsewhere (via dynamic
scoping)? If yes, how?
Couldn't it be the case only if they were defined with setq (so called
free variables)?



  reply	other threads:[~2013-05-17 12:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-04 13:01 sending function arguments to recursive function calls Gauthier Östervall
2013-05-04 15:30 ` Drew Adams
2013-05-07 11:25   ` Gauthier Östervall
2013-05-07 14:04     ` Drew Adams
2013-05-08 12:21       ` Stefan Monnier
2013-05-09  8:35         ` Gauthier Östervall
2013-05-09 12:23           ` Stefan Monnier
2013-05-12 13:19             ` Gauthier Östervall
2013-05-13 14:55               ` Stefan Monnier
2013-05-17 12:20                 ` Gauthier Östervall [this message]
2013-05-17 12:26                   ` Dmitry Gutov
2013-05-17 14:31                     ` Drew Adams
2013-05-19 16:57                       ` Dmitry Gutov
2013-05-21 16:34                         ` Drew Adams
     [not found]                       ` <mailman.70.1368982677.22516.help-gnu-emacs@gnu.org>
2013-05-19 20:59                         ` Pascal J. Bourguignon
2013-05-20 19:31                           ` Dmitry Gutov
     [not found]                           ` <mailman.94.1369078320.22516.help-gnu-emacs@gnu.org>
2013-05-20 19:55                             ` Pascal J. Bourguignon
2013-05-07 14:32     ` Pascal J. Bourguignon
     [not found]     ` <mailman.25279.1367935468.855.help-gnu-emacs@gnu.org>
2013-05-07 14:55       ` Pascal J. Bourguignon
2013-05-08 12:25         ` Stefan Monnier
2013-05-05  1:22 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAM8gEgjSxngm69rEm4AyQm9=SuPtvucwc3p2VfbJ3bAs8EXPRg@mail.gmail.com' \
    --to=gauthier@ostervall.se \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).