General pathname comments

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

    Date: Tue, 13 Jun 89 18:28 EDT
    From: 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*.

That's fine for PARSE-NAMESTRING, but Common Lisp has a function PATHNAME that
takes only a namestring, with no argument for a host, and lots of functions are
specified to call it implicitly.  So there has to be some way to get a pathname
 from just a string.  CLtL p.415 refers to the ideas of "manifest host name"
and "explicit host name" (probably the same thing?) in namestrings, but doesn't
define what they are.  Nonetheless, it seems clear that there has to be a way
to include host specifications in namestrings, at least in some implementations.

    ....
    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.

You're right that whatever the printed representation printed for a pathname,
it shouldn't depend on random special variables like *DEFAULT-PATHNAME-DEFAULTS*.
It should contain a "manifest host name."

    2. Perhaps *DEFAULT-PATHNAME-DEFAULTS* should be generalized.  I seem to
    remember (at least) one of the LispM implementations had per-host defaults.

Symbolics pathnames originally worked that way and it was a real disaster.
I would strongly argue against it.

    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.

I don't understand why you would want to parse a pathname in a syntax different
 from the syntax of the host you are going to use it with, but I'll defend to the
death your right to do it.  In other words I think Common Lisp has to allow some
implementation variance in the syntax of file names, since it depends on criteria
that X3J13 can't know in advance.