Re: Issue: PATHNAME-WILD (version 5)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I'll try again to explain my confusion (!) about TRANSLATE-PATHNAME.
I think a large part of the problem is that I just don't understand
what the motivation is for making this function as complicated as it
is.

My understanding is that this function is actually performing *two*
distinct operations: first, it performs a pattern match on
<from-wildcard> and <source>; and then it combines <to-wildcard> with
the result of that operation in a kind of merging procedure that fills
in wildcard fields as well as empty fields.  My confusion is about why
these two operations have been glued together like this instead of
being made into two separate primitives.  It seems like the merging
operation by itself would be quite useful, but I'm having a hard time
imagining an example where you really need the combined operation.
(The rationale section doesn't address this, and it seems like the
RENAME-FILES example could be accomplished with only the merging
primitive.)  Is reversibility a property of the matching operation or
the merging operation, or both?  Perhaps if the combined functionality
and the whole business about reversibility are only needed to support
logical pathnames, they should be made part of that proposal instead? 

After giving this proposal another reading, I have a two additional
unrelated comments.  First, WILD-PATHNAME-P and PATHNAME-MATCH-P ought
to be allowed to return "true" instead of T.  Second, I think that if
we allow DELETE-FILE not to signal an error when given a wildcard
pathname, that RENAME-FILE also ought to be allowed not to signal an
error.

-Sandra
-------