From: wgreenhouse@riseup.net (W. Greenhouse)
To: help-gnu-emacs@gnu.org
Subject: Re: Declaring a local dynamic variable?
Date: Sat, 28 Sep 2013 07:21:01 +0000 [thread overview]
Message-ID: <874n951kf6.fsf@motoko.kusanagi> (raw)
In-Reply-To: 52467C53.7000405@easy-emacs.de
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
[...]
> BTW not sure if we are speaking at the same thing, resp. if this might
> be expressed by "lexical" or "dynamic" already.
>
> IMO it's convenient to use and change a let-bound var in downward
> functions, whithout the need to hand it over via arguments etc. Just
> a convenience, it saves keystrokes, a major reason for me to use
> Emacs.
>
> Maybe "let" should already provide what "declare" does?
You're right, maybe we don't quite understand each other.
To reiterate:
As it stands now, the byte compiler throws a warning when it sees a
function refer to a variable which is neither bound inside the function
(e.g. by `let', by the function's arglist, etc.) nor defined globally.
Variables bound by `let' do not throw the warning. And this is not a
"dynamic" vs. "lexical" problem--the variables in question are already
dynamic for sure, because, not being bound inside the text of their
function, they can't possibly be lexically bound! This situation is
analogous to the failed call to `getx' in the example under the second
paragraph of (info "(elisp) Lexical Binding").
So the warning is there for good reason. When you're using dynamic
binding in your library, the warning tells you that you possibly made a
typo and should check to make sure you aren't setting the wrong thing.
Where you're using lexical binding, it tells you that your function
which refers to variable `foo' will certainly fail to pick up the
lexically bound `foo' in the calling function. Either way, it is
something you probably want to know about.
You are of course able to use dynamic variables to pass state around
between two functions, even in a library that uses lexical-binding. The
compiler's just going to complain about you doing so with, e.g., `setq'
without declaring the variable first. The point is also made in (info
"(elisp) Dynamic Binding Tips") that, since such "utility" dynamic
variables are accessible to all of Emacs, they should be usefully named
to avoid collisions with similar functions, and maybe even have a
docstring. Nudging the programmer to use `defvar' or `declare' for
these dynamic "utility" variables therefore seems appropriate.
--
Regards,
WGG
next prev parent reply other threads:[~2013-09-28 7:21 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-20 9:52 Declaring a local dynamic variable? Joost Kremers
2013-09-20 12:30 ` Stefan Monnier
2013-09-20 14:54 ` Andreas Röhler
[not found] ` <mailman.2569.1379688787.10748.help-gnu-emacs@gnu.org>
2013-09-20 15:10 ` Barry Margolin
2013-09-20 16:34 ` Andreas Röhler
[not found] ` <mailman.2578.1379694764.10748.help-gnu-emacs@gnu.org>
2013-09-20 20:59 ` Barry Margolin
2013-09-21 5:49 ` Andreas Röhler
[not found] ` <mailman.2622.1379742443.10748.help-gnu-emacs@gnu.org>
2013-09-21 11:31 ` Barry Margolin
2013-09-21 13:32 ` Andreas Röhler
[not found] ` <mailman.2638.1379770251.10748.help-gnu-emacs@gnu.org>
2013-09-22 3:49 ` Barry Margolin
2013-09-23 16:26 ` Joost Kremers
2013-09-23 21:17 ` Barry Margolin
2013-09-23 22:14 ` Joost Kremers
2013-09-24 0:03 ` Barry Margolin
2013-09-25 8:58 ` Joost Kremers
2013-09-23 16:19 ` Joost Kremers
2013-09-22 17:11 ` Pascal J. Bourguignon
2013-09-23 16:17 ` Joost Kremers
2013-09-24 21:40 ` Stefan Monnier
2013-11-02 23:56 ` WJ
2013-11-03 1:42 ` WJ
[not found] ` <mailman.2566.1379680283.10748.help-gnu-emacs@gnu.org>
2013-09-23 16:11 ` Joost Kremers
2013-09-24 21:34 ` Stefan Monnier
2013-09-25 5:52 ` Andreas Röhler
2013-09-25 7:24 ` Stefan Monnier
2013-09-25 8:43 ` Joost Kremers
2013-09-25 12:26 ` Stefan Monnier
2013-10-12 16:54 ` Andreas Röhler
[not found] ` <mailman.3886.1381596756.10748.help-gnu-emacs@gnu.org>
2013-10-12 21:25 ` Kai Grossjohann
2013-10-13 8:12 ` Andreas Röhler
2013-10-13 13:37 ` Stefan Monnier
2013-10-13 17:41 ` Andreas Röhler
2013-10-13 19:56 ` Kai Großjohann
[not found] ` <mailman.2843.1380112007.10748.help-gnu-emacs@gnu.org>
2013-09-25 15:46 ` Barry Margolin
2013-09-25 18:53 ` Stefan Monnier
2013-09-27 9:53 ` Andreas Röhler
2013-09-27 13:15 ` Stefan Monnier
[not found] ` <mailman.2982.1380275511.10748.help-gnu-emacs@gnu.org>
2013-09-27 14:31 ` Barry Margolin
2013-09-27 18:48 ` Andreas Röhler
[not found] ` <mailman.3016.1380307597.10748.help-gnu-emacs@gnu.org>
2013-09-27 20:18 ` Pascal J. Bourguignon
2013-09-27 23:57 ` Stefan Monnier
2013-09-28 6:20 ` Andreas Röhler
2013-09-28 6:24 ` W. Greenhouse
2013-09-28 6:50 ` Andreas Röhler
2013-09-28 7:21 ` W. Greenhouse [this message]
[not found] ` <mailman.2873.1380135245.10748.help-gnu-emacs@gnu.org>
2013-09-26 0:06 ` Barry Margolin
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=874n951kf6.fsf@motoko.kusanagi \
--to=wgreenhouse@riseup.net \
--cc=help-gnu-emacs@gnu.org \
/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).