From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: never use `eval' Date: Fri, 17 Jul 2015 04:16:03 +0200 Message-ID: <877fpzil5o.fsf@nl106-137-147.student.uu.se> References: <87io9lmb4z.fsf@mbork.pl> <87oajdkqc7.fsf@kuiper.lan.informatimago.com> <87zj2w29ch.fsf@nl106-137-147.student.uu.se> <87d1zrlfz6.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1437099480 9333 80.91.229.3 (17 Jul 2015 02:18:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jul 2015 02:18:00 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jul 17 04:17:51 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZFvDj-0007Aa-7h for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Jul 2015 04:17:51 +0200 Original-Received: from localhost ([::1]:42562 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFvDi-0000fG-Dj for geh-help-gnu-emacs@m.gmane.org; Thu, 16 Jul 2015 22:17:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFvDW-0000f7-Gq for help-gnu-emacs@gnu.org; Thu, 16 Jul 2015 22:17:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFvDT-00022x-5s for help-gnu-emacs@gnu.org; Thu, 16 Jul 2015 22:17:38 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:38926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFvDS-00022a-R2 for help-gnu-emacs@gnu.org; Thu, 16 Jul 2015 22:17:35 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZFvDR-00076x-My for help-gnu-emacs@gnu.org; Fri, 17 Jul 2015 04:17:33 +0200 Original-Received: from nl106-137-156.student.uu.se ([130.243.137.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Jul 2015 04:17:33 +0200 Original-Received: from embe8573 by nl106-137-156.student.uu.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Jul 2015 04:17:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 121 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nl106-137-156.student.uu.se Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:bq+LCyFeiB/GvFI4Z3F7JDOB9r4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:105769 Archived-At: "Pascal J. Bourguignon" writes: > It should not be a problem, at that time, or > nowadays. In the old days, car and cdr were quite > the optimized instructions: they corresponded to > 7090 machine instructions, or to lisp machine > instructions, so calling (car x) several times was > probably faster than storing the result in > a variable or even a register (because of the > possible register spilling) and calling it up again. > > And nowadays, with honest compilers performing some > common subexpression elimination optimization, it > should compile to exactly the same. Yeah, it is more a question of the code not looking good and being difficult to work with, say for example if the data item that once was (car l) changes - you have to change all them places. You can do search-and-replace but then you better catch them all and since it is such a common thing you might catch some unwanted fish in the bargain/net as well. I don't really care about speed as such, but of course I want to write efficient code. Still computers have always been always fast enough for me, and I have used old computers (5-10 years) all my "career". What I do don't require speed it would seem and besides I don't think I'm that slow just because I don't disassemble code to compare which is preferable. I'm on the human side of the equation. I can't even say how many cache levels my architecture has. OK, 'lscpu' tells me three, but you know what I'm saying. > In the case of ccl, the code is quite similar, but > indeed (car x) (car x) will hit the (cache) memory > each time, recomputing the offset (assumedly in the > pipeline so at zero cost) each time, while using > a temporary variable saves it in a register. "ccl" I don't know. > But in the case of sbcl, it compiles to the exact > same instructions (the only difference being in the > procedure entry, probably allocating some space on > the stack that is left unused in the let case). Steel Bank Common Lisp! (defvar inferior-lisp-program) (setq inferior-lisp-program "/usr/bin/sbcl --noinform") Did the US steel industry have a bank, which had its own a dialect of LISP? Crazy times... Probably a lot of job opportunities for real programmers in those days. > Again, if you have tail call optimization, then > there's no recursion occuring, and efficiency is > equivalent to iteration (because in effect, the > compiler generates an iteration). I do like some recursion which uses one function (itself) and do recursion there. This recursion pattern is cool: * empty list - nil * not empty list - do something with car - do it again with cdr The recursion I don't like is recursion which relies on helper functions and "accumulator" variables and the like - them arguments should be input data, not "persistent variables" to carry state between invocations. Some recursion can be with an infix operator and then do recursion divide-and-conquer both ways down searching a tree, then leading up to the operands of the function. It looks cool to be sure. But the coolest search algorithm I've seen is "candidate elimination" which searches search space two ways, from the general to the specific, and simultaneously, form the specific to the general, and where they meet is the answer (no nodes left to go to but to stay put). This reminds me of what happened once in the FOSS world when there was a non-free component of KDE, namely Qt (pronounced "cute"?) - to counterpunch this, two projects were launched: GNOME, to replace KDE - i.e., the general approach; and, Harmony to replace Qt (the specific). The end of the story is GNOME was succesful (still not to my liking, but I don't like the desktop at all); Harmony was dropped (?); and, Qt turned free. It is just the way of the street. In 100 years the same thing will happen and people will be angry and creative about it. Then and now and in the future, the only thing bigger than the grievance is the mirth. > Of course, CL implementations and emacs lisp don't > necessarily implement TCO, so recursion could be > less efficient. But as long as response times are > below the 300 ms threshold, it's ok. ;-) Right. When the carpenter applies sandpaper to a piece of wood, he doesn't think a person will get stuck by every single chip he removes. But if he didn't do it at all, and used the plank to lay a floor, the shoe-less hippies and their dogs would cry out their spits and angers... "If everything can start anew, then everything must continue." -- underground experts united http://user.it.uu.se/~embe8573