Issue: PATHNAME-LOGICAL (version 3)

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

    Date: Wed, 21 Jun 89 21:34 EDT
    From: Barry Margolin <barmar@Think.COM>

      10. TRANSLATE-LOGICAL-PATHNAME pathname                        [Function]

	If the coerced argument is a logical pathname, the first matching
	translation (according to PATHNAME-MATCH-P) of the logical pathname
	host is applied, using TRANSLATE-PATHNAME with the reversible argument
	true.  If the result is a logical pathname, this process is repeated.
	Three values are returned:
	  1. The physical pathname
	  2. The from-wildcard of the translation
	  3. The to-wildcard of the translation

    If the translation process has to be repeated, which wildcards are
    returned as values 2 and 3, the first or the last?  

Neither.

							It seems to me that
    in order to be useful, this must return the entire sequence of wildcard
    pairs that were used.  The description later says:

	they might be
	modified to reflect multiple levels of translation and/or additional
	translations

    Maybe this is answering my question, but I'm unsure whether a single
    pair of wildcards can represent a sequence of translations; I guess the
    question is whether wildcard translations form a group, or something
    like that (my math theory is a bit rusty).

That text was supposed to answer your question, as was the example that
begins ";For Unix with 14-character file names, using .l as the type".
In retrospect it wasn't nearly as clear as it should have been.

The fact that I think you are overlooking is that the -only- requirement
on the second and third values from TRANSLATE-LOGICAL-PATHNAME is the
identity given in point 10 of the proposal.  They do not have to be
general wildcards that can translate -anything- back to a logical pathname,
the proposal only requires them to work for the particular physical
pathname that was returned.  Thus to-wildcard could be equal to the
physical pathname and from-wildcard could be equal to the logical pathname.
This would translate that one physical pathname back to that one logical
pathname.

Of course it's better if an implementation returns more generally useful
wildcard pathnames; I wanted to formulate a stronger constraint on the
implementation but couldn't think of one.  The best I've been able to do
so far is that if component X has a value of :WILD (or NIL) in every
level of translation, then component X in the result should be :WILD;
apply this rule separately to from and to.  Should this be put in to
the proposal by amendment, or am I trying to overspecify here?

The other possibility would be to eliminate all support for back
translation by eliminating the extra return values from TRANSLATE-PATHNAME
and TRANSLATE-LOGICAL-PATHNAME (we would add these functions to the list
that implementations are allowed to extend by adding extra values).
This would certainly simplify things and might be for the best.
The more I think about it the more I like this idea, perhaps I'll come
to the meeting prepared with amendments to these two proposals.