unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stephen Berman <stephen.berman@gmx.net>,
	Noam Postavsky <npostavs@users.sourceforge.net>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	Tino Calancha <f92capac@gmail.com>,
	23781@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)	[thread overview]
Message-ID: <3f71a58c-98d9-4ed0-9d16-62d96a263255@default> (raw)
In-Reply-To: <87y45svs6i.fsf@gmx.net>

> > 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.





  parent reply	other threads:[~2016-06-26  2:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17  5:19 bug#23781: 25.0.95; read-string with HIST lexically bound Tino Calancha
2016-06-17 15:25 ` Michael Heerdegen
2016-06-23 23:01   ` Noam Postavsky
2016-06-23 23:18     ` Drew Adams
2016-06-25  0:26       ` Noam Postavsky
2016-06-25 10:12         ` Stephen Berman
2016-06-25 16:53           ` Noam Postavsky
2016-06-25 18:53             ` Stephen Berman
2016-06-25 19:46               ` Noam Postavsky
2016-06-25 22:07                 ` Stephen Berman
2016-06-25 23:42                   ` Michael Heerdegen
2016-06-26  3:34                     ` Noam Postavsky
2016-06-27  0:55                       ` Noam Postavsky
2016-07-01  4:07                         ` npostavs
2016-06-26  2:23                   ` Drew Adams [this message]
2016-06-25 21:00               ` Drew Adams
2016-06-25 20:42             ` Drew Adams
2016-06-24  2:24     ` Tino Calancha

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=3f71a58c-98d9-4ed0-9d16-62d96a263255@default \
    --to=drew.adams@oracle.com \
    --cc=23781@debbugs.gnu.org \
    --cc=f92capac@gmail.com \
    --cc=michael_heerdegen@web.de \
    --cc=npostavs@users.sourceforge.net \
    --cc=stephen.berman@gmx.net \
    /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).