From: "Drew Adams" <drew.adams@oracle.com>
To: "'Thierry Volpiatto'" <thierry.volpiatto@gmail.com>
Cc: 11328@debbugs.gnu.org
Subject: bug#11328: 24.1.50; Comment in `dired-copy-file-recursive' code
Date: Thu, 26 Apr 2012 08:35:49 -0700 [thread overview]
Message-ID: <8029A2B122324A82AEAC6FC2A742F198@us.oracle.com> (raw)
In-Reply-To: <87ipgngi26.fsf@gmail.com>
> 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
next prev parent reply other threads:[~2012-04-26 15:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-24 17:37 bug#11328: 24.1.50; Comment in `dired-copy-file-recursive' code Drew Adams
2012-04-24 17:49 ` Drew Adams
2012-04-24 18:22 ` Drew Adams
2012-04-25 13:40 ` Nix
2012-04-25 16:26 ` Drew Adams
2012-04-25 18:42 ` Thierry Volpiatto
2012-04-25 21:51 ` Drew Adams
2012-04-26 5:48 ` Thierry Volpiatto
2012-04-26 14:09 ` Drew Adams
2012-04-26 15:35 ` Drew Adams [this message]
2012-04-26 18:38 ` Thierry Volpiatto
2012-04-24 18:54 ` Stefan Monnier
2014-02-09 4:32 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8029A2B122324A82AEAC6FC2A742F198@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=11328@debbugs.gnu.org \
--cc=thierry.volpiatto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.