bug#11328: 24.1.50; Comment in `dired-copy-file-recursive' code

["Drew Adams" <drew.adams@oracle.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