let-bind a varlist only known at run time

let-bind a varlist only known at run time

[Roland Winkler]

Normally the varlist for the special let form is hardcoded.  Is it
possible to specify the varlist only at runtime?

The usage scenario I have in mind is that a user variable foo-alist
may hold an alist that becomes the varlist for the let-binding.  So
it's not known at compile time which bindings a user might want to
specify in foo-alist.  Also, it might be hard to predict an
exhaustive list of "candidate variables" a user might want to put into
foo-alist (and certainly such a list would be hard to maintain).

On the other hand, I expect that efficiency is not an issue for the
body appearing in let.  So if there is nothing else I could
construct the complete let-form at runtime and pass it on to `eval'.
But maybe there is a better solution...

Thanks!

Roland

Re: let-bind a varlist only known at run time

[Michael Heerdegen]

"Roland Winkler" <winkler@gnu.org> writes:

> Normally the varlist for the special let form is hardcoded.  Is it
> possible to specify the varlist only at runtime?

`cl-progv'?

> On the other hand, I expect that efficiency is not an issue for the
> body appearing in let.  So if there is nothing else I could construct
> the complete let-form at runtime and pass it on to `eval'.

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.


Michael.

Re: let-bind a varlist only known at run time

[Roland Winkler]

On Mon Jun 5 2017 Michael Heerdegen wrote:
> 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!)

So is this a bug in cl-progv?  (I checked: this macro ignores the
2nd arg LEXICAL of eval.)

Re: let-bind a varlist only known at run time

[Michael Heerdegen]

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

Re: let-bind a varlist only known at run time

[Roland Winkler]

On Wed Jul 12 2017 Michael Heerdegen wrote:
> > 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.

I agree that the expressions need to be evaluated only once.
Currently cl-progv uses the quoted values of the expresssions for
the let binding.  I expect that instead, these quoted values should
be used twice, for the let binding and for `eval'.

I played with this idea, but I couldn't find a solution within the
finite amount of time I spent with this problem.

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

Thanks, I'll watch it.

Re: let-bind a varlist only known at run time

[Philipp Stephani]

Roland Winkler <winkler@gnu.org> schrieb am So., 4. Juni 2017 um 23:00 Uhr:

> Normally the varlist for the special let form is hardcoded.  Is it
> possible to specify the varlist only at runtime?
>
> The usage scenario I have in mind is that a user variable foo-alist
> may hold an alist that becomes the varlist for the let-binding.  So
> it's not known at compile time which bindings a user might want to
> specify in foo-alist.  Also, it might be hard to predict an
> exhaustive list of "candidate variables" a user might want to put into
> foo-alist (and certainly such a list would be hard to maintain).
>

Have you checked `let-alist'? Maybe it already does what you want.

Re: let-bind a varlist only known at run time

[Roland Winkler]

On Mon Jun 5 2017 Philipp Stephani wrote:
> Have you checked `let-alist'? Maybe it already does what you want.

Thanks, yes, I had looked at it.  It is my understanding that
let-alist is intended for sets of bindings that are known at compile
time so that one can use the syntax with dotted symbols.  What I
envision is different: the bindings refer to various options for the
code executed inside BODY, where this code may even include calls to
customizable functions (i.e., these functions may use options defined
by the user that are not known at the compile time for BODY).  So it
seems that `cl-progv' mentioned by Michael is essentially what I am
looking for.