From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11328: 24.1.50; Comment in `dired-copy-file-recursive' code Date: Thu, 26 Apr 2012 08:35:49 -0700 Message-ID: <8029A2B122324A82AEAC6FC2A742F198@us.oracle.com> References: <0CC212AF2EA740A0B8FE5EEF91077A2D@us.oracle.com><9DC04CC6E710430F90675022247AF8C1@us.oracle.com><6D7414BA5657418E9D2AB4D0AA0E71A3@us.oracle.com><87y5pk53ra.fsf@spindle.srvr.nix><87ty07hcv7.fsf@gmail.com> <87ipgngi26.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1335454640 5345 80.91.229.3 (26 Apr 2012 15:37:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2012 15:37:20 +0000 (UTC) Cc: 11328@debbugs.gnu.org To: "'Thierry Volpiatto'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 26 17:37:19 2012 Return-path: Envelope-to: geb-bug-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 1SNQkv-0003aH-J0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Apr 2012 17:37:17 +0200 Original-Received: from localhost ([::1]:33110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQku-0002pY-Sk for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Apr 2012 11:37:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52903) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQkr-0002pC-JT for bug-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:37:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNQkh-00053O-79 for bug-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:37:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNQkh-00053K-3E for bug-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:37:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SNQld-0002hv-NX for bug-gnu-emacs@gnu.org; Thu, 26 Apr 2012 11:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Apr 2012 15:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11328 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11328-submit@debbugs.gnu.org id=B11328.133545462110329 (code B ref 11328); Thu, 26 Apr 2012 15:38:01 +0000 Original-Received: (at 11328) by debbugs.gnu.org; 26 Apr 2012 15:37:01 +0000 Original-Received: from localhost ([127.0.0.1]:54431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SNQke-0002gN-AO for submit@debbugs.gnu.org; Thu, 26 Apr 2012 11:37:01 -0400 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]:31174) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SNQkb-0002g9-9Z for 11328@debbugs.gnu.org; Thu, 26 Apr 2012 11:36:58 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3QFZpSE022012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Apr 2012 15:35:52 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3QFZoIC014948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 15:35:51 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3QFZolI030377; Thu, 26 Apr 2012 10:35:50 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Apr 2012 08:35:50 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ipgngi26.fsf@gmail.com> Thread-Index: Ac0jcCi2XaRUhSYHQsaOMcYglp6IjgAS8HAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:59523 Archived-At: > Just take example of TARGET, that could be an argument of > `dired-create-files' instead of using NAME-CONSTRUCTOR. > [Currently] you must give TARGET to d-c-files within a lambda > (NAME-CONSTRUCTOR) > It would be more clear to call d-c-files like this: > > (dired-create-files > fn > (symbol-name action) > files > ;; The `if' form above containing the lambda > ;; is now in `dired-create-files' > target ; Give it TARGET to handle. > marker) As I explained, in the particular case of NAME-CONSTRUCTOR and TARGET the caller does not in fact ever need (make use of) the _variable_ TARGET. All it needs is its value, i.e., the value at the time and place that the lambda is constructed, in `d-do-create-files'. So there is no need to include the _variable_ itself in the lambda form. It is sufficient to use its value there. That is clearer to read and is cleaner code. And there is no need either to pass TARGET as an additional argument to `d-create-files'. > > E.g., in the NAME-CONSTRUCTOR arg that is passed by > > `dired-do-create-files' to `dired-create-files', the code > > could use this, substituting TARGET's value > > instead of leaving TARGET as a free var in the lambda: > > > > `(lambda (from) > > (expand-file-name (file-name-nondirectory from) ',target)) > > > > instead of: > > > > (lambda (from) > > (expand-file-name (file-name-nondirectory from) target)) > > This would be even more complex to understand how to use d-c-files. I don't think so. It has nothing to do with how to use `d-c-files'. Do you find this clearer? (lambda (from) (expand-file-name (file-name-nondirectory from) "/foo/bar")) I assume so. No TARGET variable there. I've just substituted its current value at the time the lambda form was constructed (i.e., in `d-do-create-files') - let's assume "/foo/bar" in this call to `d-do-create-files'. How about this? (list 'lambda (list 'from) (list 'expand-file-name (list 'file-name-nondirectory 'from)) (symbol-value 'target)) Those three are all the same thing (assuming TARGET is "/foo/bar" in `d-do-create-files'). The point is that the lambda form need not contain the (free) variable TARGET at all. It is enough that it use the variable's _value_. And Occam's razor says that if it need not then it should not - just get the value at lambda construction time/place and plug it in. The caller of the lambda need never bother with the variable at all, in any context. Again, however, this is the simple case - NAME-CONSTRUCTOR. In other cases the caller does in fact use the variable itself, looking it up in some particular context to get its value there, or perhaps even setting it. But in this simple case the caller does not need the variable - its value at the time and place of the lambda construction is all that is needed. And the code is clearer if we make that explicit. No sense letting a reader mistakenly think that the caller might somehow use the variable TARGET. In fact, it takes a bit of looking at the code to realize this. Far better to make it clear to readers from the outset. > > Or it could just use the latter if TARGET were lexically > > bound with the right value. In that case the lambda would form a > > closure. In that case, we would be encapsulating the variable's binding at the lambda construction place (not time, however, since binding is lexical). That's overkill, but it amounts to the same thing. The only difference is that the variable value would be looked up when the lambda is _used_, not when it was constructed. But that use-time lookup just returns the value that was in play at the time of the lambda construction. So same effect in the end. HTH - Drew