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?