From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Alan Mackenzie <acm@muc.de>, emacs-devel@gnu.org
Subject: RE: Can't M-x compile-defun `edebug' because dynamic variables are falsely taken as lexical.
Date: Thu, 13 Feb 2020 17:07:47 -0800 (PST) [thread overview]
Message-ID: <837a062d-8fb0-4b41-bc53-d96a166263a4@default> (raw)
In-Reply-To: <jwv36benntq.fsf-monnier+emacs@gnu.org>
> > But I'm afraid I don't know what a permanent versus
> > temporary special variable is. And I haven't found
> > anything in the doc that has helped me with that.
>
> It's the term used in the part that describes `defvar`:
>
> Note that specifying a value, even @code{nil},
> marks the variable as special permanently.
Thanks.
[FWIW, I'm no expert in any of this. I'm just trying
(1) to understand what the Emacs story is about this
and (2) to reconcile that with what I think about the
Common Lisp story about it. Limited understanding of
both, no doubt. Also, I'm not arguing for any change,
including a realignment with CL, if there is in fact a
difference. I just want the doc to be make sense and
be clear about what Emacs does. So far, it doesn't
seem clear to me.]
____
Permanently is not the opposite of locally. Instead
of "permanently", shouldn't that text say "globally"?
I think what you mean there is what Common Lisp calls
"indefinite scope" - there are no limits on the scope
of a special variable, i.e., _where_ it can be
referenced.
(As contrasted with "indefinite extent", which is what
lexical bindings provide - no limit on _when_ the var
can be referenced - the binding can last as long as
there is still some reference to the variable.)
If you said "globally" then that text would no longer
seem to directly contradict the statement that "The
variable is marked as 'special', meaning that it
should _always_ be dynamically bound", which is in
the very same node, `Defining Variables'.
But although not seeming to directly contradict, even
that wouldn't really be right, I think. More correct
would be to say "'special', meaning that it should be
bound dynamically _everywhere_". Everywhere, not
always.
Dynamic binding, i.e., the binding of a special var,
is indefinite with respect to _where_ (it's global) -
what CL calls "indefinite scope". And it's dynamic
with respect to _when_ (how long) - what CL calls
"dynamic extent".
Continuing...
> if @var{value} is omitted then the variable is only
> marked special locally (i.e.@: within the current
> lexical scope, or file if at the top-level).
This feature doesn't exist in Common Lisp, AFAIK.
In CL, `(defvar foo)' _proclaims_ `foo' to be special,
just like `(proclaim (special foo))', and that means
that it's special _everywhere_.
In CL, `defvar' always proclaims the variable special,
whether or not an initial value is provided. Without
an initial value the variable has no global value and
it's called "unbound".
> > AFAIK, in Common Lisp a variable is either special
> > or it's not. If it is then its binding by `let'
> > is dynamic, and if it's not then its let-binding
> > is lexical. (No?)
>
> Same for us.
I don't see that, so far. I think maybe you're saying
(and perhaps the doc is saying) that a var that is not
bound lexically in some particular context is special
_in that context_ (not everywhere), and that the same
variable can be bound either lexically or dynamically.
And I think that for CL, a variable that is ever
special is always and everywhere special, i.e., in
all contexts. It's always bound dynamically.
When you say "Same for us", I'm guessing maybe you're
interpreting what I wrote with "special" having your
special ;-) interpretation as being context-dependent:
"If it is [special] then its binding by `let'
is dynamic, and if it's not [special] then its
let-binding is lexical."
Am I guessing right wrt your interpretation of
"special"? For you (and thus Emacs terminology),
can a var be sometimes special and sometimes not?
I don't think that's the case for the way CL uses
"special variable".
However, CL does say that about a given _name_ of
a variable. The same name can refer in some places
to a special var and in other places to a lexical
var. This is what CLTL says:
At any given time either or both kinds of variable
with the same name may have a current value.
Which of the two kinds of variable is referred to
when a symbol is evaluated depends on the context
of the evaluation.
The general rule is that if the symbol occurs
textually within a program construct that creates
a _binding_ for a variable of the same name, then
the reference is to the variable specified by the
binding; if no such program construct textually
contains the reference, then it is taken to refer
to the special variable of that name.
IOW, there can be a special variable `foo' and one
or more lexical variables `foo'. They have the same
name but they're different variables.
I think the terminology you're using would say that
it's the same variable, and it's sometimes, or in
some places, special and at other times, or in other
places, lexical.
> Does Common Lisp offer something like `special-variable-p`?
Not that I know of. But it also doesn't use `defvar'
with and without second arg to declare specialness.
`defvar' always declares specialness (proclaims,
actually).
next prev parent reply other threads:[~2020-02-14 1:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-03 14:14 Can't M-x compile-defun `edebug' because dynamic variables are falsely taken as lexical Alan Mackenzie
2017-01-03 18:35 ` Stefan Monnier
2017-01-03 21:32 ` Alan Mackenzie
2017-01-03 21:48 ` Stefan Monnier
2017-01-04 13:39 ` Alan Mackenzie
2017-01-04 15:23 ` Stefan Monnier
2017-01-04 20:04 ` Alan Mackenzie
2017-01-04 21:49 ` Stefan Monnier
2017-01-04 22:02 ` Alan Mackenzie
2017-01-04 22:26 ` Stefan Monnier
2017-01-04 22:44 ` Drew Adams
2017-01-05 10:54 ` Alan Mackenzie
2020-02-13 16:42 ` Drew Adams
2020-02-13 20:02 ` Stefan Monnier
2020-02-13 20:43 ` Drew Adams
2020-02-13 22:09 ` Stefan Monnier
2020-02-14 1:07 ` Drew Adams [this message]
2020-02-14 2:24 ` Stefan Monnier
2020-02-14 17:25 ` Drew Adams
2020-02-14 19:19 ` Stefan Monnier
2020-02-17 18:23 ` Drew Adams
2020-02-13 22:11 ` Stefan Monnier
2020-02-14 1:13 ` Drew Adams
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=837a062d-8fb0-4b41-bc53-d96a166263a4@default \
--to=drew.adams@oracle.com \
--cc=acm@muc.de \
--cc=emacs-devel@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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).