Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)

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

    Date: Thu, 29 Dec 88 14:54 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Thu, 29 Dec 88 13:29 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Also I don't understand what your proposed semantic/syntactic
	distinction ...

    Semantic means you have to probe the file system. Syntactic means
    looking at the file names themselves is enough. Maybe I screwed up
    the presentation. I'll double-check.

OK, I understand, and you did screw up the presentation.

	But if they were only allowed immediately after :RELATIVE I
	don't think you would need two of them.

    I claim my example above refutes this.

Agreed.

	I also don't think that
	MERGE-PATHNAMES should ever look at what files/directories actually
	exist in the file system,

    If you permit :UP in absolute pathnames, you don't have to look in the
    file system. You just get some funny names. Most file systems that 
    have this feature permit such funny names, though. eg, /foo/../bar/x
    is valid in Unix, I understand. If memory serves me, Multics permits
    >foo>bar>baz<x>y in Multics, no? 

No.  Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.

I think you got syntactic and semantic mixed up again.  I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do.  Okay.

These names are extremely confusing, obviously.  Can anyone think
of better ones than :UP and :BACK?

				     Our (Symbolics) pathname system doesn't
    permit embedded "<", but the error message suggests that this is only
    because there's no obvious interpretation. 

The error message I get doesn't suggest anything, it's just "Embedded <?".

					       We could define it to mean
    :BACK rather than :UP, so that syntactic merges could be done and
    unique pathnames would always be generated.

I don't understand this sentence.  Say it again after we all agree on
which one is :UP and which one is :BACK.

	which makes me opposed to the existence
	of the one that you have called syntactic.

    In any case, I'm sympathetic to your desire to not look in the file
    system. I just think that if a file system designer has made a
    decision that forces you to look in the file system to get the right
    answer, I don't know what we the CL designers can do to alter that.
    The same issue comes up for logical devices and as Sandra has reminded
    us, we've not done a particularly good job of papering over that real
    externally-induced issue either.

	Is this really something we need, or will TRUENAME do the job?

    TRUENAME and OPEN would, presumably, not return pathnames with :UP
    references (except maybe in pathological situations which they tell
    me you can make in Unix if you try hard enough where the only way to
    get to a directory is to go down first and then dig upward.)

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

    Nothing forces a file system to have both. The question is whether
    there are some file systems that have one set of semantics and others
    which have the other. If so, then two tokens are needed. In the discussion
    leading up to this, people asserted (and I took them at their word) that
    there were such competing semantics.

I don't know enough about the weird file systems out there to dispute this.

    Well, there was the whole treatment of :UP. I hadn't really meant for this
    proposal to specify that treatment so much as to identify a common representation
    so we'd be a little less divergent in the areas we hadn't really specified.
    Does anyone think I should add a disclaimer in the proposal body similar to the
    one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
    although these are semi-standard names, there is no attached semantics?

Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics.  I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed
meanings.