Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)

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

I approve PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION but note the
following typos and proposed simplifications.  Also, don't you need
functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY?  The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not.  Also in some systems the root directory has a name and in others
it doesn't.  Of course these functions signal an error in
non-hierarchical file systems.  Should there be a separate proposal for
these?

Typos (and some discussion):

    Problem Description:

      - In some implementations "FOO.BAR" might denote the "BAR" subdirectory
        of "FOO" while in other implementations because "." is not the
        separator.

Some words must be missing after "while".

    Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)

       :UP         - Go upward in directory structure (semantic).
       :BACK       - Go upward in directory structure (syntactic).
      The difference between up and back is that if there is a directory
        (:ABSOLUTE "X" "Y" "Z")
      linked to 
        (:ABSOLUTE "A" "B" "C")
      and there also exist directories
        (:ABSOLUTE "A" "B" "Q")
        (:ABSOLUTE "X" "Y" "Q")
      then
        (:ABSOLUTE "X" "Y" "Z" :OUT "Q")
      designates
        (:ABSOLUTE "A" "B" "Q")
      while
        (:ABSOLUTE "X" "Y" "Z" :UP "Q")
      designates
        (:ABSOLUTE "X" "Y" "Q")

Is :OUT a typo for :BACK?  Also I don't understand what your proposed
semantic/syntactic distinction is.  I almost thought I did until I read
the above text carefully and saw that the syntactic one chases links
to the truename and the semantic one does not, which seems backwards.

I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me.  But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.  I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system, which makes me opposed to the existence
of the one that you have called syntactic.  Is this really something
we need, or will TRUENAME do the job?

I think we should only have :UP and not :BACK.

    Current Practice:

       - Genera represents Unix ".." as :UP, but deals with :UP 
         syntactically, not semantically.

After you straighten out the definition of syntactic and semantic, check
whether this statement is true.  (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).

    Discussion:

      This issue used to address the issue of relative pathnames (pathnames
      relative to some default which is separately maintained). Pitman removed
      this issue for now in order to simplify things. He feels the issue should
      be resubmitted under separate cover so that it can be discussed separately.

It seems to me that this fully addresses relative pathnames already.  The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent.  A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.