General pathname comments

[Kim Barrett <IIM@ECLA.USC.EDU>]

None of this should be taken as actual proposals.  I'm mostly pointing out some
places where I think there are still problems.

1. Something that always bothered me about the Symbolics pathname system, which
seems to be unstated but present in these proposals, is the mechanism for
parsing strings to pathnames.  There seems to be an unstated assumption that
the parsing will try to find a host specification in the string and parse
according to the syntax of that host.  I believe it is wrong to try to parse
the string in order to determine how to parse the string.  That's what the Host
and Defaults arguments for PARSE-NAMESTRING are for, and I think it would be
better to clarify that, and make recommendations about specifying arguments to
PARSE-NAMESTRING or binding *DEFAULT-PATHNAME-DEFAULTS*.

As an example, consider a namestring of "SYS:FOO.LISP", with
*DEFAULT-PATHNAME-DEFAULTS* bound to a pathname whose syntax specifies that the
device is followed by a ":" (TOPS-20 satisfies this, but I seem to remember
there is an ambiguity in TOPS-20 pathnames, at least in the Symbolics
implementation, in that the host is also followed by a ":").  Should this
namestring be parsed into a logical pathname whose host is SYS, or should it be
parsed using  the parsing algorithm for the host in
*DEFAULT-PATHNAME-DEFAULTS*?

Of course, I may be completely off base with these comments.  But I think not,
based in part on what people claim are reasonable printed representations for
pathnames.  Both the #P"..." and #.(PATHNAME "...") printed representations
really require that you can in some way infer the proper parsing algorithm by
looking at the string.  Otherwise, changing the value of
*DEFAULT-PATHNAME-DEFAULTS* would break the print/read invertability.  I
pointed some of this out in mail a while back when there was some discussion
about the printed representations of pathnames.

2. Perhaps *DEFAULT-PATHNAME-DEFAULTS* should be generalized.  I seem to
remember (at least) one of the LispM implementations had per-host defaults.
This might cause problems for figuring out what syntax to use for parsing
though (see 1 above).

3. Something we (IIM) provide is an escape for the parsing (we parse according
to the host or defaults arguments to PARSE-NAMESTRING, unless this escape hatch
is invoked).  We chose a syntax that doesn't conflict with the syntax of any
file system we know of, namely using curly braces.  If the string begins with a
substring surrounded by curly braces, then that substring specifies the host
whose syntax is to be used to parse the remainder of the string.  For example:

  namestring :=  "{MY-TOPS-20}MY-MSDOS:X:<FOO.BAR>BAZ"

  (PARSE-NAMESTRING namestring)

   => ;; regardless of the value of *DEFAULT-PATHNAME-DEFAULTS*

      #.(PARSE-NAMESTRING "[MY-MSDOS]X:/FOO/BAR/BAZ" "MY-MSDOS")

  (NAMESTRING namestring) => "[MY-MSDOS]X:/FOO/BAR/BAZ"

(We put square-brackets around the host in our extension to MSDOS file syntax).
Note that the curly-brace host is only used to determine the algorithm to be
used for parsing, not defaulting or anything like that.