need for 'dynamical-let'?

need for 'dynamical-let'?

[Stephen Leake]

I'm switching on lexical-binding in some files.

In several cases, the byte compiler is complaining:

xgit.el:993:30:Error: add-to-list cannot use lexical var `branch-list'

So I have to change code like this:

(let (branch-list
      ...)
   (add-to-list branch-list (substring branch-entry 2) t)


to:

(defvar dvc-branch-list);; add-to-list can't use lexical var
(let (
      ...)
   (add-to-list 'dvc-branch-list (substring branch-entry 2) t)


This pollutes the global name space, and disguises the local nature of
'branch-list'.

Can we define a macro 'dynamical-let' that would implement this
pattern, but with hidden variables?

-- 
-- Stephe

Re: need for 'dynamical-let'?

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> I'm switching on lexical-binding in some files.
>
> In several cases, the byte compiler is complaining:
>
> xgit.el:993:30:Error: add-to-list cannot use lexical var `branch-list'
>
> So I have to change code like this:
>
> (let (branch-list
>       ...)
>    (add-to-list branch-list (substring branch-entry 2) t)
>
>
> to:
>
> (defvar dvc-branch-list);; add-to-list can't use lexical var
> (let (
>       ...)
>    (add-to-list 'dvc-branch-list (substring branch-entry 2) t)
>
>
> This pollutes the global name space, and disguises the local nature of
> 'branch-list'.
>
> Can we define a macro 'dynamical-let' that would implement this
> pattern, but with hidden variables?


Also, how do I know which functions I write also can't use lexical
variables? Using 'symbol-value' would be one clue, apparently. I hope
the byte-compiler will complain?

-- 
-- Stephe

Re: need for 'dynamical-let'?

[Dmitry Gutov]

On 07/23/2015 11:54 PM, Stephen Leake wrote:

> So I have to change code like this:
>
> (let (branch-list
>        ...)
>     (add-to-list branch-list (substring branch-entry 2) t)
>
>
> to:
>
> (defvar dvc-branch-list);; add-to-list can't use lexical var
> (let (
>        ...)
>     (add-to-list 'dvc-branch-list (substring branch-entry 2) t)

You should use `push'. Or maybe `cl-pushnew'.

need for 'dynamical-let'?

[Stephen J. Turnbull]

Stephen Leake writes:

 > Can we define a macro 'dynamical-let' that would implement this
 > pattern, but with hidden variables?

First, was there a typo in your post?  add-to-list normally takes a
(quoted) symbol.  Since the argument isn't quoted, it appears that the
effect is that you are attempting to add-to-list to the variable (not
the value!) nil.  Assuming that was a typo....

`dynamical-let' is about as ugly as ugly can get, and anyway it
shouldn't be necessary.  The variable is lexically apparent and its
value is not magical in any way.  Your code *should* work.

Try running your code in the interpreter.  I suspect it will work when
the function is actually called (in compiled code there's a compiler
macro so the function is never called).  Why not fix that instead?

Or, perhaps, as Dmitry and the add-to-list docstring suggest, you
should convert the code to use `push' or `pushnew' instead.  The
inconvenience of the busybody compiler macro may be considered a
"feature" intended to encourage you to modernize your code.

Re: need for 'dynamical-let'?

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Stephen Leake writes:
>
>  > Can we define a macro 'dynamical-let' that would implement this
>  > pattern, but with hidden variables?
>
> First, was there a typo in your post?  add-to-list normally takes a
> (quoted) symbol.  Since the argument isn't quoted, it appears that the
> effect is that you are attempting to add-to-list to the variable (not
> the value!) nil.  Assuming that was a typo....
>
> `dynamical-let' is about as ugly as ugly can get, and anyway it
> shouldn't be necessary.  The variable is lexically apparent and its
> value is not magical in any way.  Your code *should* work.

add-to-list is a function (not a macro) taking a symbol as indicator of
a variable.  So lookup happens at run time when the lexical environment
is already gone.  No way this can happen lexically.

-- 
David Kastrup

Re: need for 'dynamical-let'?

[Stephen Leake]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Stephen Leake writes:
>
>  > Can we define a macro 'dynamical-let' that would implement this
>  > pattern, but with hidden variables?
>
> First, was there a typo in your post?  add-to-list normally takes a
> (quoted) symbol.  

Yes, that's a typo

> `dynamical-let' is about as ugly as ugly can get, and anyway it
> shouldn't be necessary.  The variable is lexically apparent and its
> value is not magical in any way.  Your code *should* work.

add-to-list uses 'symbol-value' on the quoted symbol. As David Kastrup
points out, and as symbol-value doc string says, that does not see
lexical values. So the code will not work.

> Or, perhaps, as Dmitry and the add-to-list docstring suggest, you
> should convert the code to use `push' or `pushnew' instead.  

I was working in Emacs 24.3, where the add-to-list doc string does not
mention "push". But the Emacs master doc string does mention it.

> The inconvenience of the busybody compiler macro may be considered a
> "feature" intended to encourage you to modernize your code.

Ok.

-- 
-- Stephe

Re: need for 'dynamical-let'?

[Stephen Leake]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 07/23/2015 11:54 PM, Stephen Leake wrote:
>
>> So I have to change code like this:
>>
>> (let (branch-list
>>        ...)
>>     (add-to-list branch-list (substring branch-entry 2) t)
>>
>>
>> to:
>>
>> (defvar dvc-branch-list);; add-to-list can't use lexical var
>> (let (
>>        ...)
>>     (add-to-list 'dvc-branch-list (substring branch-entry 2) t)
>
> You should use `push'. Or maybe `cl-pushnew'.

Except that 't' means add at tail, not at head. Is there a cl-* for
that? I only found 'cl-revappend'.

I can use 'append', followed by 'delete-dups'.

-- 
-- Stephe

Re: need for 'dynamical-let'?

[Dmitry Gutov]

On 07/24/2015 11:16 AM, Stephen Leake wrote:

> Except that 't' means add at tail, not at head. Is there a cl-* for
> that? I only found 'cl-revappend'.

I don't know the code you're editing, but I haven't had a need for that. 
Instead, in similar situations, I `push' in a loop, and do a (setq foo 
(nreverse foo)) in the end.

> I can use 'append', followed by 'delete-dups'.

That's also an option.

Re: need for 'dynamical-let'?

[Dmitri Paduchikh]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

SL> Can we define a macro 'dynamical-let' that would implement this
SL> pattern, but with hidden variables?

Not sure about pattern with hidden variables, but `dynamical-let' which
would always establish dynamic binding will be useful for writing macros.
Currently, if I understand right, expansion of the macro

(defmacro foo ()
  '(let ((some-variable t))
     (bar)))

is treated differently depending on the current value of `lexical-binding':
the macro will create lexical binding where this variable is t, and dynamic
binding otherwise. This is bad as it can easily introduce unintended
behavior changes to code. `dynamical-let' would provide some control to
macro writers. Natively supported `lexical-let' would be also good to have.
But may be give them somewhat shorter names.

Re: need for 'dynamical-let'?

[Stefan Monnier]

> (let (branch-list
>       ...)
>    (add-to-list 'branch-list (substring branch-entry 2) t)

This is butt-ugly and ridiculously inefficient.
In such code, don't use add-to-list (which is OK for configuring
global vars, but not for such situations) and don't use the t argument
which makes the operation O(N).
As Dmitry says, using `push' or `cl-pushnew', and if need the object in
some other order, re-order them later, e.g. with nreverse.


        Stefan

Re: need for 'dynamical-let'?

[Dmitri Paduchikh]

It seems that the situation with advices even worse than with macros. As
I understand it, the code of advice may be compiled at runtime but it is
unknown in what context compilation will be done. There is even no
expansion point for it, so it seems that compilation is done in a
completely random environment. Nothing can be said about value of
`lexical-binding' and set of defvars. Not sure that my understanding is
correct though.

Re: need for 'dynamical-let'?

[Stefan Monnier]

> It seems that the situation with advices even worse than with macros. As
> I understand it, the code of advice may be compiled at runtime but it is
> unknown in what context compilation will be done.

That's true for old-style `defadvice', but not for new-style
`advice-add'.


        Stefan

Re: need for 'dynamical-let'?

[Dmitri Paduchikh]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It seems that the situation with advices even worse than with macros. As
>> I understand it, the code of advice may be compiled at runtime but it is
>> unknown in what context compilation will be done.

SM> That's true for old-style `defadvice', but not for new-style
SM> `advice-add'.

Understood. Is it planned to obsolete `defadvice'?

Re: need for 'dynamical-let'?

[Stefan Monnier]

>>> It seems that the situation with advices even worse than with macros. As
>>> I understand it, the code of advice may be compiled at runtime but it is
>>> unknown in what context compilation will be done.
SM> That's true for old-style `defadvice', but not for new-style
SM> `advice-add'.
> Understood. Is it planned to obsolete `defadvice'?

Yes,


        Stefan

Re: need for 'dynamical-let'?

[Dmitri Paduchikh]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> It seems that the situation with advices even worse than with macros. As
>>>> I understand it, the code of advice may be compiled at runtime but it is
>>>> unknown in what context compilation will be done.
SM>>> That's true for old-style `defadvice', but not for new-style
SM>>> `advice-add'.
>> Understood. Is it planned to obsolete `defadvice'?
SM> Yes,

Ah, thank you for clarifications.

Re: need for 'dynamical-let'?

[raman]

Please dont obsolete defadvice yet  -- emacspeak is entirely written in
defadvice, and even if we were to verify that the new advice mechanism
lets it do everything it does with defadvice, rewriting it in terms of
nadvice would be a large project in of its own. 
--