Reliable sources have told me that CLtL2 mandates that
TRANSLATE-PATHNAME should give the following results:
(translate-pathname "host:prefix-foo.lisp"
"host:prefix-*.*"
"host:prefix;*.*")
==> #P"host:prefix;prefix-foo.lisp"
NOT #P"host:prefix;foo.lisp"
(translate-pathname "host:foo;x.lisp"
"host:foo;**;*.*"
"host:**;*.*")
==> #P"host:foo;x.lisp"
NOT #P"host:x.lisp"
I was informed that my expectation of a "reversible" translation was
specifically rejected by the CL committee. Why? Also, can anyone
tell me how to get my intended results, perhaps with different
wild-card patterns?
Thanks,
Steve
·····@parc.xerox.com
In article <······················@parc.xerox.com> ·····@parc.xerox.com (Stephen E. Miner) writes:
>Reliable sources have told me that CLtL2 mandates that
>TRANSLATE-PATHNAME should give the following results:
>
>(translate-pathname "host:prefix-foo.lisp"
> "host:prefix-*.*"
> "host:prefix;*.*")
>==> #P"host:prefix;prefix-foo.lisp"
>NOT #P"host:prefix;foo.lisp"
>
>(translate-pathname "host:foo;x.lisp"
> "host:foo;**;*.*"
> "host:**;*.*")
>==> #P"host:foo;x.lisp"
>NOT #P"host:x.lisp"
I don't have CLtL2 handy; however, the X3J13 proposal writeup mandates very
little about the precise translation that is done. It says, "The portion
of <source> that is copied into <result> is implementation defined."
However, it then goes on to describe "typical" behavior, as well as some of
the behavior of the implementation upon which the design was based
(Symbolics Genera). Genera's behavior is used in the examples section as
well.
I agree with you in both cases about what would be reasonable behavior.
Genera agrees with you in the second case, but not the first. The examples
in the writeup only include a case of your first example; there is no
mention of wild-inferiors in the entire proposal. In the to-wildcard
argument, Genera distinguishes a :WILD component from one that contains an
embedded wildcard; a :WILD component is translated to the entire
corresponding component of the source, ignoring the from-wildcard
component, whereas an embedded wildcard is only translated to the portion
of the source component that doesn't match the non-wild part of the
from-wildcard. Thus, you get the following discontinuity:
(translate-pathname "foo-bar" "foo-*" "a*") => #P"abar"
(translate-pathname "foo-bar" "foo-*" "*") => #P"foo-bar"
The reason for this behavior is that the from-wildcard pathname is often
doing double duty; it is used to select files to operate on, as well as to
specify the translation, because TRANSLATE-PATHNAME may be called
internally by other functions. For example:
(rename-file "dir1;foo-*.lisp" "dir2;*.*")
This could mean "move all the Lisp source files in dir1 with the prefix
'foo-' to dir2", or it could mean "move all the Lisp source files in dir1
with the prefix 'foo-' to dir2, and remove the prefix", and Symbolics chose
the former interpretation. In the above case, it's ambiguous; to a human,
the intent of the following is pretty obvious:
(rename-file "dir1;foo-*.lisp" "foo;*.lisp")
but a computer has trouble distinguishing these two examples.
However, this is only an example implementation; I repeat, the precise
rules are implementation-dependent.
By the way, the only system I've ever used that had a really good pathname
translation convention is Multics. The to-wildcards use "=" instead of
"*"; a single "=" translates to whatever matched the corresponding "*" in
the from-wildcard, while "==" translates to the entire corresponding source
component ("=" is treated as "==" when the corresponding from-wildcard
component is not wild).
>I was informed that my expectation of a "reversible" translation was
>specifically rejected by the CL committee. Why? Also, can anyone
>tell me how to get my intended results, perhaps with different
>wild-card patterns?
Reversible translation isn't required because the translation is
implementation-dependent. The idea of this function is that it provides a
portable interface to an existing implementation or OS facility or
convention. I don't know whether reversible translation was ever
discussed (there's no mention of it in the PATHNAME-WILD writeup).
However, an early version of the proposal for logical pathnames
incorporated backtranslation support. Here's the relevant excerpt from the
PATHNAME-LOGICAL writeup:
Symbolics Genera offers a function for translating from a physical
pathname back to a logical pathname. There are a number of problems with
this, and so it has not been proposed here. An earlier version specified
TRANSLATE-LOGICAL-PATHNAME to return enough information to allow the user
program to perform the backtranslation itself, but that had problems
so it was removed.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar