CLHS: Issue PATHNAME-HOST-PARSING Writeup

#

## Issue PATHNAME-HOST-PARSING Writeup

    Issue:        PATHNAME-HOST-PARSING
    Forum:	      X3J13
    References:   Pathnames chapter
    Category:     CHANGE
    Edit history: 06-Jul-93, Version 1 by Pitman
    	      08-Jul-93, Version 2 by Pitman
    	        (fix Cost To Users and add Discussion per Barmar)
                  08-Jul-93, Version 3 by Pitman
    	        (address physical/logical conflicts per Barmar)
    Status:		Proposal RECOGNIZE-LOGICAL-HOST-NAMES passed (6+3)-3
    		on letter ballot 93-306.

    Problem Description:

     Substantial confusion has been caused to numerous users over the issue
     of "FOO:BAR;BAZ.LISP" parsing as a non-logical pathname in namestring,
     and (MAKE-PATHNAME :host "FOO" ...) constructing a non-logical pathname
     when "FOO" designates a logical pathname host.  There is widespread
     sentiment that this model must change.

    Proposal (PATHNAME-HOST-PARSING:HOST-COLON):

     Define that when parsing a namestring with respect to an explicitly
     named host (as with PARSE-NAMESTRING with a host argument), the
     namestring is parsed in the manner normal for that host.

     Define that when parsing a namestring with no explicitly named host
     (as with all calls to PATHNAME, and calls to PARSE-NAMESTRING where
     no host is given explicitly):
       - a namestring containing no colon is to be interpreted as a
         host-specific namestring on the current default host.
       - in a namestring that contains at least one colon, the first
         colon is taken to terminate the end of a host name.  (If the host
         name is the null string, "", the current default host is
         assumed.)  Any subsequent string is a host-specific namestring
         for the host named by the text preceding the colon.

     Define that if host is defined as a logical host at namestring parse
     time, then it will be recognized as such by the namestring parser, and
     a logical pathname will result from a situation in which a logical host
     was named in the host part of a namestring.

     Remove the function LOGICAL-PATHNAME, since the functions PATHNAME
     and PARSE-NAMESTRING suffice instead.

     Require #P to always use a host name to print, for the sake of portability
     among multiple implementations that all have access to the same file
     system.

     If an attempt is made to parse a namestring containing a host name
     that is defined both as a physical and a logical host, the effects
     are implementation defined.

    Proposal (PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES):

     Define that if host is defined as a logical host at pathname
     construction time, then it will be recognized as such by the namestring
     parser, and a logical pathname will result from a situation in which a
     logical host was named in the host part of a namestring.

     If an attempt is made to construct a pathname specifying a host name
     that is defined both as a physical and a logical host, the effects
     are implementation defined.

    Test Case:

      For option HOST-COLON:

        "BAR;BAZ"  is a filename on the default host.
        ":BAR;BAZ" is notationally equivalent to "BAR;BAZ".
        "FOO:BAR;BAZ" is a filename on a host "FOO".
          If that host is a logical host, then this designates a logical
          pathname. If that host is not a logical host, then this designates
          a physical pathname.

        In the case where an ambiguity might result, for example, where
        there was both a device named "SYS" on a VMS host "V", and a host
        named "SYS", the following notations (which follow from the rules
        outlined above) can be used to disambiguate:

          ":SYS:FOO" refers to device SYS on the default host.
          "SYS:FOO"  refers to "FOO" on host "SYS".

     For option RECOGNIZE-LOGICAL-HOST-NAMES:

       (MAKE-PATHNAME :HOST "FOO")
       works to name a logical host FOO just as
       (MAKE-PATHNAME (PATHNAME-HOST (LOGICAL-PATHNAME "FOO:")))
       would do.

     For option

    Rationale:

     These options would legitimize the observed desires of numerous users.

    Current Practice:

     Both of these options are consistent with long-standing Genera practice,
     which Symbolics users have generally been extremely happy with and have
     often asked other vendors to be consistent with.

    Cost to Implementors:

     Small to medium:
      Some isolated changes to the pathname parsing code.
      Probably the biggest cost will be in checking existing tools to make
       sure none make inappropriate assumptions about the parsing rules.

    Cost to Users:

     Medium:

      Probably most users don't do things that are in the boundary case,
      except that there may be some who use ":" in a namestring without
      it referring to a host.  Experience with Genera suggests that there
      will be an initial flurry of concern about this, but that in the long
      run users will be very much happier.

      The one situation that might come up a lot is where programs prompt
      users for a filename and then parse that name without adding a leading
      ":".  Such calls could be fixed by using a host-specific parse instead.

    Cost of Non-Adoption:

     Continued intermittent confusion and irritation about the rules for
     logical pathname parsing.

    Benefits:

     Making #P print portably will improve the portability of code that is
     processed through PRINT/READ and that has pathname literal constants
     in it.

    Editorial Impact:

     Not trivial, but not huge:  A number of isolated small changes.

    Aesthetics:

     This definitely improves the aesthetics for most users by putting logical
     hosts on an even footing with physical hosts.  It also simplifies the user
     model since most users don't understand why
       :host logical-host
     is ok but
       :host logical-host-name
     is not, since most things that take names also take the named object, and
     since there are other operators that can reliably perform this
     transformation.  This change makes the language more consistent in that
     regard.

    Discussion:

     These changes address comments Yen #1 and Barrett #31.

     Pitman thinks all of these changes are a good idea.

     Barrett asked that we specify that:
      ``logical pathname namestrings are valid pathname designators''
     Pitman hopes that the above satisfies the intent of that, but
     worries that since some logical pathname namestrings already were
     (e.g., "foo.bar") and just happened not to designate logical pathnames,
     this would be a confusing way to express the change.  The change affects
     only those logical pathname namestrings which have a host name visible
     and for which there is no competing definition as a device, etc.
     The wording chosen above is intended to make an end run around this
     potential pitfall.

     Barmar says:
      Genera gets away with [HOST-COLON] because the Lisp parsing rules
      are consistent with those used by the Genera OS (hardly a
      coincidence).  Users expect pathname parsing to be consistent within
      an OS, not subject to the choice of implementation language by the
      programmer.

      Consider a program that prompts the user for a file name and then parses
      it.  The user will most likely use the normal pathname syntax for his
      system; on a PC that would be something like "c:\foo\bar.baz", and on
      VMS it might be "SYS$FOO:[BAR]BAZ.QUUX".  Users of such programs should
      not be expected to know which programs are written in Lisp, which
      imposes different pathname parsing rules from all other programs on the
      OS.

      At the very least there needs to be a way for programs to force the CLtL
      pathname interpretation rules.  Are you proposing that such programs
      should simply prepend a colon to the namestring read in?  Considering
      that VMS has its own syntax for remote pathnames, what should be the
      result of (pathname-host ":HOST::DEV:[DIR]NAME.EXT") on a VMS system?
      The HOST-COLON proposal says that it should be the current default host,
      but VMS pathname interpretation implies that it should be something
      derived from "HOST".

      I'd like to hear some commentary from vendors and users of Lisps for
      VMS, Macs, and MS-DOS.  Does CLOE use this pathname parsing strategy?
      Were users actually happy with it?

Copyright 1996-2005, LispWorks Ltd. All rights reserved.