* Re: Lexical let and setq
@ 2013-09-16 15:59 Barry OReilly
0 siblings, 0 replies; 11+ messages in thread
From: Barry OReilly @ 2013-09-16 15:59 UTC (permalink / raw)
To: bn.troels, chrismgray, rms; +Cc: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <871u51ll93.fsf@yandex.ru>]
[parent not found: <jwvzjrly386.fsf-monnier+emacs@gnu.org>]
[parent not found: <jwvhadps8a1.fsf-monnier+emacs@gnu.org>]
[parent not found: <0b29ebee-8ed4-47e2-816b-910a013a0898@default>]
[parent not found: <jwvzjrhqrft.fsf-monnier+emacs@gnu.org>]
* Lexical let and setq [not found] ` <jwvzjrhqrft.fsf-monnier+emacs@gnu.org> @ 2013-09-14 0:09 ` Michael Welsh Duggan 2013-09-14 3:46 ` Stefan Monnier 2013-09-14 21:47 ` Richard Stallman 0 siblings, 2 replies; 11+ messages in thread From: Michael Welsh Duggan @ 2013-09-14 0:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 0:09 ` Michael Welsh Duggan @ 2013-09-14 3:46 ` Stefan Monnier 2013-09-14 11:13 ` Lars Magne Ingebrigtsen 2013-09-14 21:47 ` Richard Stallman 1 sibling, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2013-09-14 3:46 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 3:46 ` Stefan Monnier @ 2013-09-14 11:13 ` Lars Magne Ingebrigtsen 2013-09-14 14:04 ` Pascal J. Bourguignon 2013-09-15 5:11 ` Stefan Monnier 0 siblings, 2 replies; 11+ messages in thread From: Lars Magne Ingebrigtsen @ 2013-09-14 11:13 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 11:13 ` Lars Magne Ingebrigtsen @ 2013-09-14 14:04 ` Pascal J. Bourguignon 2013-09-15 5:11 ` Stefan Monnier 1 sibling, 0 replies; 11+ messages in thread From: Pascal J. Bourguignon @ 2013-09-14 14:04 UTC (permalink / raw) To: emacs-devel 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 11:13 ` Lars Magne Ingebrigtsen 2013-09-14 14:04 ` Pascal J. Bourguignon @ 2013-09-15 5:11 ` Stefan Monnier 1 sibling, 0 replies; 11+ messages in thread From: Stefan Monnier @ 2013-09-15 5:11 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 0:09 ` Michael Welsh Duggan 2013-09-14 3:46 ` Stefan Monnier @ 2013-09-14 21:47 ` Richard Stallman 2013-09-15 5:09 ` Stefan Monnier 1 sibling, 1 reply; 11+ messages in thread From: Richard Stallman @ 2013-09-14 21:47 UTC (permalink / raw) To: Michael Welsh Duggan; +Cc: monnier, emacs-devel [ 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-14 21:47 ` Richard Stallman @ 2013-09-15 5:09 ` Stefan Monnier 2013-09-15 16:54 ` Richard Stallman 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2013-09-15 5:09 UTC (permalink / raw) To: Richard Stallman; +Cc: Michael Welsh Duggan, emacs-devel > Tail recursion is harder to read. We'll just agree to disagree here. This is not the place to discuss it. Stefan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-15 5:09 ` Stefan Monnier @ 2013-09-15 16:54 ` Richard Stallman 2013-09-15 17:06 ` Stefan Monnier 0 siblings, 1 reply; 11+ messages in thread From: Richard Stallman @ 2013-09-15 16:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: mwd, emacs-devel [ 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-15 16:54 ` Richard Stallman @ 2013-09-15 17:06 ` Stefan Monnier 2013-09-16 10:47 ` Richard Stallman 0 siblings, 1 reply; 11+ messages in thread From: Stefan Monnier @ 2013-09-15 17:06 UTC (permalink / raw) To: Richard Stallman; +Cc: mwd, emacs-devel > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Lexical let and setq 2013-09-15 17:06 ` Stefan Monnier @ 2013-09-16 10:47 ` Richard Stallman 0 siblings, 0 replies; 11+ messages in thread From: Richard Stallman @ 2013-09-16 10:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: mwd, emacs-devel [ 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-09-16 15:59 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-09-16 15:59 Lexical let and setq Barry OReilly [not found] <871u51ll93.fsf@yandex.ru> [not found] ` <jwvzjrly386.fsf-monnier+emacs@gnu.org> [not found] ` <jwvhadps8a1.fsf-monnier+emacs@gnu.org> [not found] ` <0b29ebee-8ed4-47e2-816b-910a013a0898@default> [not found] ` <jwvzjrhqrft.fsf-monnier+emacs@gnu.org> 2013-09-14 0:09 ` Michael Welsh Duggan 2013-09-14 3:46 ` Stefan Monnier 2013-09-14 11:13 ` Lars Magne Ingebrigtsen 2013-09-14 14:04 ` Pascal J. Bourguignon 2013-09-15 5:11 ` Stefan Monnier 2013-09-14 21:47 ` Richard Stallman 2013-09-15 5:09 ` Stefan Monnier 2013-09-15 16:54 ` Richard Stallman 2013-09-15 17:06 ` Stefan Monnier 2013-09-16 10:47 ` Richard Stallman
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).