Re: Issue: PATHNAME-WILD (version 5)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 13 Jun 89 10:36:49 MDT
    From: 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.

Thanks for continuing to pursue this, Sandra.

    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.  

That's accurate.

                                                 My confusion is about why
    these two operations have been glued together like this instead of
    being made into two separate primitives.  

Because some new object would have to be invented to carry the result of
the first operation into the second operation.  This would represent the
correspondence between the from-wildcard and the source in some way.  In
typical implementations, this is currently represented as flow of control
inside the TRANSLATE-PATHNAME function and functions that it calls.  I
wouldn't want to introduce this complicated new pathname-correspondence
object if there isn't really a need to get the first primitive by itself.

Think about (using Unix syntax):
  (translate-pathname "/usr/dmr/hacks/frob.l"
                      "/usr/d*/hacks/*.l"
                      "/usr/d*/backup/hacks/backup-*.l")
for which the answer is (assuming the wildcard conventions used by the
Unix on which I tried this):
  "/usr/dmr/backup/hacks/backup-frob.l"

Now think about:
  (translate-pathname "/usr/dmr/hacks/frob.l"
                      "/usr/d*/hacks/fr*.l"
                      "/usr/d*/backup/hacks/backup-*.l")
for which the answer is
  "/usr/dmr/backup/hacks/backup-ob.l"

Your second primitive sees only the first and third arguments, so it
has no way to distinguish these two cases.  To separate the primitives,
the first one would have to output something telling you that in the
first case, "frob" matched the wildcard, while in the second case,
"ob" matched the wildcard.  Should this example go into the proposal?

                                              It seems like the merging
    operation by itself would be quite useful, 

I agree that it's useful.  It's available as TRANSLATE-PATHNAME with the
two wildcard pathname arguments the same, isn't it?  I don't see how the
matching primitive could be used by itself.

                                               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.)  

I haven't been able to figure out how you think the RENAME-FILES example
can be done with only the merging half.  Maybe you didn't think about any
cases where the source file name has a partially wild component ("foo*"
rather than "*")?  There were two of those in the examples, but they weren't
very clear because the target file name had a full wild component in both.
I should should concoct another example to clarify this.  I clearly have a
lot of trouble coming up with examples that cover all the cases for these
things.

                 Is reversibility a property of the matching operation or
    the merging operation, or both?  

I don't know, probably both, but it depends on exactly what you had in mind
as the boundary between the two operations.

				     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? 

It's very hard to know how to modularize these proposals.  I've heard
everything from "put all pathname stuff into a single omnibus proposal
so we can understand it as a unit", to "break each feature into a
separate proposal so we can address it separately".  In the face of
that, I'm just guessing at the modularity.  I don't know about the
reversible part, but everything else is useful independent of logical
pathnames.

    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.  

I think they did in an earlier version, and some commentor made me change
it to T, so as to make the language less ambiguous.  Did you have a specific
useful value in mind for them to return?  If so, maybe we could just specify
that that is what they return.  If not, let's stick with 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.

Good point.