[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


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?


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.