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

Require #P to always use a host name to print, for the sake of portability
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
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.

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:

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?