[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-WILD (version 5)
- To: Sandra J Loosemore <email@example.com>
- Subject: Re: Issue: PATHNAME-WILD (version 5)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 13 Jun 89 14:50 EDT
- Cc: David N Gray <Gray@DSG.csc.ti.com>, CL-Cleanup@sail.stanford.edu, Gray@Kelvin.csc.ti.com
- In-reply-to: <8906131636.AA22421@defun.utah.edu>
Date: Tue, 13 Jun 89 10:36:49 MDT
From: firstname.lastname@example.org (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
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.
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):
for which the answer is (assuming the wildcard conventions used by the
Unix on which I tried this):
Now think about:
for which the answer is
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
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
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
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