Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 12 Jan 89 00:30 PST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    [lmm: from Ballot]

	I can understand why someone might find the need for :UNSPECIFIC
	in Unix unclear, but I think that is because it is not clear what
	filenames would be parsed as pathnames with :UNSPECIFIC type [*];
	:UNSPECIFIC is nonetheless useful for building pathnames directly
	when you know which case you want and need a way to specify it.

	[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
	Different Unix programs use different conventions.  Some are
	willing to merge in a type field, others, such as the C compiler,
	leave names as-is.  So the "right" answer may vary.    

Symbolics systems have a consistent rule for use in the absence of a file
system specific convention: assume that the last dot (if any) separates the
name from the type.

If there is no last dot, then the type is :UNSPECIFIC. If there is a last
dot, then the text to the right (even if null) is the type and the text to
the left (even if null) is the name.

This rule means that:
 "." has name "" and type "".
 ".." has name "." and type "".

You might say that this is not the optimal mapping, but after all:
"." and ".." were quite obviously chosen to be screwy file names so 
they wouldn't get in the way of other more important namespaces.
If you look at it that way, it's quite appropriate that they get
internal names which are not "easy" to generate.

Whether "." was name "." and type :unspecific (as I mentioned
is possible) or name "" and type "" (as we implement), it would not
merge a type. In either case, you could make a new pathname with
the same fields but with :TYPE NIL and then it would merge a type.

Anyway, just to flesh this out,
 "Foo"  has name "Foo" and type :UNSPECIFIC.
 "Foo." has name "Foo" and type ""
 "Foo.Bar.Lisp" has name "Foo.Bar" and type "Lisp"
 ".Lisp" has name "" and type "Lisp"

I wasn't involved in the choice of how this was partitioned and I admit
to being surprised at the partitioning, but I've come to believe that it
was the correct thing. For example, it would be very much the wrong thing
if a double-dot made for a dotted extension (ie, "Foo.Bar.Lisp" had name
"Foo" and type "Bar.Lisp") so you have to take the dots from the right.

It would not cause internal confusion to exempt "." and ".." and say
that they parsed as name "." and type :unspecific,etc. since in fact
there is no namestring which will parse to that. On the other hand, while
it might appease some people, it would make the rule harder to remember.

Anyway, I'm not so much proposing that we standardize this kind of thing
because personally I think it's very inappropriate for a generic
standard like the one we're making to favor some vendors over others
(since it's clear that we can't have info on everyone).  I was just trying
to give you a flavor of where I'm coming from in all this.

By the way -- someone asked about why "Foo" can't be parsed as 
name "Foo" and type NIL. The answer is that it doesn't merge correctly.
If your file defaults are something with an extension (eg, name "Foo"
and type "Lisp"), and you do (OPEN "Baz"), you should to open "Baz",
not "Baz.Lisp". If you don't, there is no way to open "Baz" without 
putting NIL in the standard pathname defaults before you do the open
to make sure that merge doesn't succeed in removing all NILs, and it's
my impression you're not supposed to be doing that kind of thing.
If  #S(PATHNAME :NAME "Foo" :TYPE :UNSPECIFIC) keeps a type from merging
and #S(PATHNAME :NAME "Foo" :TYPE NIL) allows a type to merge, then
you have the best of both worlds.