Lexical let and setq

Lexical let and setq

[Michael Welsh Duggan]

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

[...]

> I do hope to fix those issues by introducing other byte-codes which will
> let us generate significantly more efficient code for those constructs,
> but in 24.1, the priority was to get lexical-binding to work correctly,
> performance being a secondary concern (tho for most idiomatic Elisp
> code, the performance tends to be competitive).
>
> What people should know is that
>
>    (let (x y z)
>      ...(setq x ...)
>      ...(setq z ...)
>      ...(setq y ...)
>
> is often a bad idea in Elisp, and even more so in lexical-binding code
> (in some cases, if a variable is immutable it can be handled
> significantly more efficiently, so the mere existence of a single `setq'
> on a variable can sometimes slow other chunks of code: in many cases
> `let' is cheaper than `setq').

The primary reason I have seen the (let (foo) (setq foo ...)) idiom is
in looping code.  The way I would normally try to avoid this idiom in
most FP languages would be to use recursion (specifically tail
recursion, if possible).  I know some work was done on implementing
efficient tail-recursion in the byte compiler.  Has any of that made it
onto the trunk yet?

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Lexical let and setq

[Stefan Monnier]

> The primary reason I have seen the (let (foo) (setq foo ...)) idiom is
> in looping code.

That one is OK, since recursion is not supported efficiently.
The problem is when people use the above because they're writing (poor)
C code in Elisp (e.g. they begin their functions with a big let
declaring all the local vars that they may use later on in the
function).


        Stefan

Re: Lexical let and setq

[Lars Magne Ingebrigtsen]

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

> That one is OK, since recursion is not supported efficiently.
> The problem is when people use the above because they're writing (poor)
> C code in Elisp (e.g. they begin their functions with a big let
> declaring all the local vars that they may use later on in the
> function).

I think the most common reason for stashing a lot of variables in a let
is to avoid infinite indentation.

(let ((a (foo)))
  (something)
  (let ((b (something-else)))
    (more a b)
    (let ((c (yet-more)))
      (zot a b c))))

vs

(let ((a (foo))
      b c)
  (something)
  (setq b (something-else))
  (more a b)
  (setq c (yet-more))
  (zot a b c))

I kinda think the latter form is sometimes more readable.  

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Lexical let and setq

[Pascal J. Bourguignon]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> That one is OK, since recursion is not supported efficiently.
>> The problem is when people use the above because they're writing (poor)
>> C code in Elisp (e.g. they begin their functions with a big let
>> declaring all the local vars that they may use later on in the
>> function).
>
> I think the most common reason for stashing a lot of variables in a let
> is to avoid infinite indentation.
>
> (let ((a (foo)))
>   (something)
>   (let ((b (something-else)))
>     (more a b)
>     (let ((c (yet-more)))
>       (zot a b c))))
>
> vs
>
> (let ((a (foo))
>       b c)
>   (something)
>   (setq b (something-else))
>   (more a b)
>   (setq c (yet-more))
>   (zot a b c))
>
> I kinda think the latter form is sometimes more readable.  

Err, no.  A form with less indentation MAY be more readable, but not
when it's a procedural form with a setq every other subform.

If something similar and systematicall occurs from one level of
indentation to the other, then you can write a macro that will do this
uniform something, and have a unindented body:

   (something-similar 
       (foo)
       (something)
       (something-else)
       (more)
       (yet-more)
       (zot))


A simple example would be:

  (defmacro pipe (input &rest functions)
    (pipe-aux input functions))
 
  (defun pipe-aux (input functions)
    (if functions
        (pipe-aux (list (first functions) input)
                  (rest functions))
        input))
 
  (macroexpand '(pipe foo a b c d e f g)) ; --> (g (f (e (d (c (b (a foo)))))))

So you just write

  (pipe foo
     a
     b
     c
     d
     e
     f
     g)

or rather:

  (pipe foo a b c d e f g)



But in case of your let, it is much harder to read, because now you must
rebuild the data flow from the variables and setq expressions.  The
indented form was much clearer, because you can more easily skip a
subexpression, knowing for sure that whatever happens to variables in
subexpressions can't affect the rest.



-- 
__Pascal Bourguignon__
http://www.informatimago.com/

Re: Lexical let and setq

[Stefan Monnier]

> I think the most common reason for stashing a lot of variables in a let
> is to avoid infinite indentation.

> (let ((a (foo)))
>   (something)
>   (let ((b (something-else)))
>     (more a b)
>     (let ((c (yet-more)))
>       (zot a b c))))

> vs

> (let ((a (foo))
>       b c)
>   (something)
>   (setq b (something-else))
>   (more a b)
>   (setq c (yet-more))
>   (zot a b c))

> I kinda think the latter form is sometimes more readable.  

In SML (where `setq' is not an option), the natural way to write it is
equivalent to:

   (let* ((a (foo))
          (_ (something))
          (b (something-else))
          (_ (more a b))
          (c (yet-more)))
     (zot a b c))


-- Stefan

Re: Lexical let and setq

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    The primary reason I have seen the (let (foo) (setq foo ...)) idiom is
    in looping code.

I have written code that way simply to make it clearer to read.

      The way I would normally try to avoid this idiom in
    most FP languages

We should not try to avoid it.  We should make it work
just as efficiently as if it were written the other way.

With lexical scope, it is not hard to determine that the lexical
variable's value is never used until after the setq.  Then it
can be compiled as immutable.

We suggest Emacs Lisp as a path for non-programmers to learn to
program, so we need to encourage styles that are natural.  That means
loops, not tail recursion.  Tail recursion is harder to read.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Lexical let and setq

[Stefan Monnier]

> Tail recursion is harder to read.

We'll just agree to disagree here.  This is not the place to discuss it.


        Stefan

Re: Lexical let and setq

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

If you have in mind something as radical as pushing Emacs Lisp coding
towards use of tail recursion, it had better be discussed first.
I think that would be a disaster.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Lexical let and setq

[Stefan Monnier]

> If you have in mind something as radical as pushing Emacs Lisp coding
> towards use of tail recursion.

I love recursion, but I have no idea where you got the impression that
I'd like to do that.


        Stefan

Re: Lexical let and setq

[Richard Stallman]

        [ To any NSA and FBI agents reading my email: please consider
        [ whether defending the US Constitution against all enemies,
        [ foreign or domestic, requires you to follow Snowden's example.

    > If you have in mind something as radical as pushing Emacs Lisp coding
    > towards use of tail recursion.

    I love recursion, but I have no idea where you got the impression that
    I'd like to do that.

Your previous message seemed to say so.  If that was a misunderstanding
on my part, we don't need to discuss it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Lexical let and setq

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

> If you have in mind something as radical as pushing Emacs Lisp
> coding towards use of tail recursion.

I don't know what "push Emacs Lisp coding towards use of tail
recursion" means in precise terms, but hopefully Troels Nielsen [1] or
Chris Gray [2] are still working on tail call optimization.

[1] http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00473.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00286.html

[-- Attachment #2: Type: text/html, Size: 686 bytes --]