From: Michael Heerdegen <michael_heerdegen@web.de>
To: Roland Winkler <winkler@gnu.org>
Cc: help-gnu-emacs@gnu.org
Subject: Re: let-bind a varlist only known at run time
Date: Wed, 12 Jul 2017 23:59:42 +0200 [thread overview]
Message-ID: <87h8yhfh9t.fsf@drachen> (raw)
In-Reply-To: <52038.28949.342810.22836@gargle.gargle.HOWL> (Roland Winkler's message of "Sun, 4 Jun 2017 22:08:54 -0500")
"Roland Winkler" <winkler@gnu.org> writes:
> > FWIW that's what `cl-progv' is doing, more or less. The body is pasted
> > into a lambda constructed before calling eval so that it can be
> > compiled. The resulting semantics can be a bit surprising, though; for
> > example
> >
> > (let ((x 0))
> > (cl-progv (list 'x) (list 1)
> > (funcall (lambda () x))))
> >
> > yields 0 with lexical-binding on, and
> >
> > (cl-progv (list 'x) (list 1)
> > (funcall (lambda () x)))
> >
> > yields 1.
>
> Thanks, I thought about that:
>
> If var-list is the VARLIST for the let form, you should also use
> var-list to construct the alist that becomes the 2nd arg LEXICAL of
> eval. I believe, then it should not matter whether you have lexical
> binding on or off (untested!)
I don't think it's that simple: BINDS is unevaluated: it's a list of the
form ((SYMBOL EXPRESSION) ...). We would need to evaluate the bindings
twice (once to calculate the environment for `eval', and the second time
when evaluating the constructed form), which is unacceptable.
> So is this a bug in cl-progv? (I checked: this macro ignores the
> 2nd arg LEXICAL of eval.)
I think it's a bug, it's now filed as #27674.
Regards,
Michael.
next prev parent reply other threads:[~2017-07-12 21:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-04 20:43 let-bind a varlist only known at run time Roland Winkler
2017-06-05 2:49 ` Michael Heerdegen
2017-06-05 3:08 ` Roland Winkler
2017-07-12 21:59 ` Michael Heerdegen [this message]
2017-07-12 23:09 ` Roland Winkler
2017-06-05 13:44 ` Philipp Stephani
2017-06-05 15:07 ` Roland Winkler
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8yhfh9t.fsf@drachen \
--to=michael_heerdegen@web.de \
--cc=help-gnu-emacs@gnu.org \
--cc=winkler@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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.