GNU bug report logs - #23781
25.0.95; read-string with HIST lexically bound

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Tino Calancha <f92capac <at> gmail.com>, 23781 <at> debbugs.gnu.org
Subject: bug#23781: 25.0.95; read-string with HIST lexically bound
Date: Sat, 25 Jun 2016 19:23:57 -0700 (PDT)

> > So can we agree on this updated wording? (as shown in attached patch)
> >
> >        Note that unlike dynamic variables which are tied to the symbol
> >     object itself, the relationship between lexical variables and
> >     symbols is only present in the interpreter (or compiler).
> >     Therefore, functions which take a symbol argument (like
> >     ‘symbol-value’, ‘boundp’, and ‘set’) can only retrieve or modify a
> >     variable’s dynamic binding (i.e., the contents of its symbol’s
> >     value cell).  Also, the code in the body of a ‘defun’ or
> >     ‘defmacro’ cannot refer to surrounding lexical variables.
> 
> This sounds clearer to me, thanks.
> 
> > Should it be updated any further? (if yes, please reply with concrete
> proposals)
> 
> I don't feel competent enough to judge that; however, Drew pointed out
> that the `(elisp) Variables' node I quoted from earlier and other places
> in the manual haven't been updated for lexical binding.  Anyway, these
> questions would be more properly assigned to a separate bug report.

My comments were probably too simplistic.  It would be good for
someone to take a close look at all of the doc about symbols,
variables, and lexical/dynamic treatment.  But it is probably
not critical.  If someone does that, s?he probably needs to be
careful, and the result, if precise, might be too unreadable
for our manual.

I agree that any such consideration is outside this bug report.

FWIW, the CLTL2 section "3. Scope and Extent" is helpful here,
even though Emacs Lisp is not Common Lisp.

You will soon see there, however, that the relation between
symbols and variables is not so straightforward.  You will
right away see "referencable entities", which have both scope
and extent and which become "established" by "the execution
of some language construct".  Referencable entities include
function parameters and other variables, and even `catch'
and `throw' tags.

I recommend a (re-)reading of that section, asking yourself
why this or that term is introduced instead of just referring
to words like "variable".  None of the terms are introduced
gratuitously.

So yes, it would be good to be precise in the Elisp manual,
but some degree of imprecision can sometimes make for more,
not less clarity. ;-)

One thing that could perhaps be made more clear in the doc
is that the Lisp reader creates symbols (and conses and
vectors and...).  I'm not sure that this is made clear.

These created symbols etc. are used when the objects resulting
from reading are later evaluated.  IOW, even a referencable
entity such as a `catch' tag is associated with a symbol when
the `catch' code is read.  Likewise, for function parameters and
other variables, including variables that use lexical binding.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.