230 lines
14 KiB
HTML
230 lines
14 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue PATHNAME-HOST-PARSING Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss257_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss258.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss259_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss257_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss258.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss259_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-HOST-PARSING Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss258.htm">PATHNAME-HOST-PARSING</A><P>
|
|
<B>Forum:</B> X3J13<P>
|
|
<B>References:</B> Pathnames chapter<P>
|
|
<B>Category:</B> CHANGE<P>
|
|
<B>Edit history:</B> 06-Jul-93, Version 1 by Pitman<P>
|
|
08-Jul-93, Version 2 by Pitman<P>
|
|
(fix Cost To Users and add Discussion per Barmar)<P>
|
|
08-Jul-93, Version 3 by Pitman <P>
|
|
(address physical/logical conflicts per Barmar)<P>
|
|
<B>Status:</B> Proposal RECOGNIZE-LOGICAL-HOST-NAMES passed (6+3)-3<P>
|
|
on letter ballot 93-306.<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Substantial confusion has been caused to numerous users over the issue<P>
|
|
of "FOO:BAR;BAZ.LISP" parsing as a non-logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> in <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>,<P>
|
|
and (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :host "FOO" ...) constructing a non-logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
when "FOO" designates a logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> host. There is widespread<P>
|
|
sentiment that this model must change.<P>
|
|
<P>
|
|
<B>Proposal (PATHNAME-HOST-PARSING:HOST-COLON):<P>
|
|
</B><P>
|
|
Define that when parsing a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> with respect to an explicitly<P>
|
|
named host (as with <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> with a host argument), the <P>
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> is parsed in the manner normal for that host.<P>
|
|
<P>
|
|
Define that when parsing a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> with no explicitly named host<P>
|
|
(as with all calls to <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A>, <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> calls to <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> where<P>
|
|
no host is given explicitly):<P>
|
|
- a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> containing no colon is to be interpreted as a<P>
|
|
host-specific <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> on the current default host.<P>
|
|
- in a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> that contains at least one colon, the first<P>
|
|
colon is taken to terminate the end of a host name. (If the host<P>
|
|
name is the null string, "", the current default host is<P>
|
|
assumed.) Any subsequent string is a host-specific <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A><P>
|
|
for the host named by the text preceding the colon.<P>
|
|
<P>
|
|
Define that if host is defined as a logical host at <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> parse<P>
|
|
time, then it will be recognized as such by the <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> parser, and<P>
|
|
a logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> will result from a situation in which a logical host<P>
|
|
was named in the host part of a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>.<P>
|
|
<P>
|
|
Remove the function <A REL=DEFINITION HREF="../Body/a_logica.htm#logical-pathname"><B>LOGICAL-PATHNAME</B></A>, since the functions <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A><P>
|
|
and <A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> suffice instead.<P>
|
|
<P>
|
|
Require #P to always use a host name to print, for the sake of portability<P>
|
|
among multiple implementations that all have access to the same file <P>
|
|
system.<P>
|
|
<P>
|
|
If an attempt is made to parse a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> containing a host name<P>
|
|
that is defined both as a physical and a logical host, the effects<P>
|
|
are implementation defined.<P>
|
|
<P>
|
|
<B>Proposal (PATHNAME-HOST-PARSING:RECOGNIZE-LOGICAL-HOST-NAMES):<P>
|
|
</B><P>
|
|
Define that if host is defined as a logical host at <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
construction time, then it will be recognized as such by the <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A><P>
|
|
parser, and a logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> will result from a situation in which a<P>
|
|
logical host was named in the host part of a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>.<P>
|
|
<P>
|
|
If an attempt is made to construct a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> specifying a host name<P>
|
|
that is defined both as a physical and a logical host, the effects<P>
|
|
are implementation defined.<P>
|
|
<P>
|
|
<B>Test Case:<P>
|
|
</B><P>
|
|
For option HOST-COLON:<P>
|
|
<P>
|
|
"BAR;BAZ" is a filename on the default host.<P>
|
|
":BAR;BAZ" is notationally equivalent to "BAR;BAZ".<P>
|
|
"FOO:BAR;BAZ" is a filename on a host "FOO".<P>
|
|
If that host is a logical host, then this designates a logical<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. If that host is not a logical host, then this designates<P>
|
|
a physical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
<P>
|
|
In the case where an ambiguity might result, for example, where<P>
|
|
there was both a device named "SYS" on a VMS host "V", and a host<P>
|
|
named "SYS", the following notations (which follow from the rules<P>
|
|
outlined above) can be used to disambiguate:<P>
|
|
<P>
|
|
":SYS:FOO" refers to device SYS on the default host.<P>
|
|
"SYS:FOO" refers to "FOO" on host "SYS".<P>
|
|
<P>
|
|
For option RECOGNIZE-LOGICAL-HOST-NAMES:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :HOST "FOO")<P>
|
|
works to name a logical host FOO just as<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>PATHNAME-HOST</B></A> (<A REL=DEFINITION HREF="../Body/a_logica.htm#logical-pathname"><B>LOGICAL-PATHNAME</B></A> "FOO:")))<P>
|
|
would do.<P>
|
|
<P>
|
|
For option <P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
These options would legitimize the observed desires of numerous users.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Both of these options are consistent with long-standing Genera practice, <P>
|
|
which Symbolics users have generally been extremely happy with and have<P>
|
|
often asked other vendors to be consistent with.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Small to medium:<P>
|
|
Some isolated changes to the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> parsing code.<P>
|
|
Probably the biggest cost will be in checking existing tools to make <P>
|
|
sure none make inappropriate assumptions about the parsing rules.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
Medium:<P>
|
|
<P>
|
|
Probably most users don't do things that are in the boundary case, <P>
|
|
except that there may be some who use ":" in a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> without <P>
|
|
it referring to a host. Experience with Genera suggests that there<P>
|
|
will be an initial flurry of concern about this, but that in the long<P>
|
|
run users will be very much happier.<P>
|
|
<P>
|
|
The one situation that might come up a lot is where programs prompt<P>
|
|
users for a filename and then parse that name without adding a leading<P>
|
|
":". Such calls could be fixed by using a host-specific parse instead.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
Continued intermittent confusion and irritation about the rules for<P>
|
|
logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> parsing.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Making #P print portably will improve the portability of code that is <P>
|
|
processed through PRINT/READ and that has <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> literal constants <P>
|
|
in it.<P>
|
|
<P>
|
|
<B>Editorial Impact:<P>
|
|
</B><P>
|
|
Not trivial, but not huge: A number of isolated small changes.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
This definitely improves the aesthetics for most users by putting logical<P>
|
|
hosts on an even footing with physical hosts. It also simplifies the user<P>
|
|
model since most users don't understand why <P>
|
|
:host logical-host<P>
|
|
is ok but<P>
|
|
:host logical-host-name<P>
|
|
is not, since most things that take names also take the named object, and<P>
|
|
since there are other operators that can reliably perform this <P>
|
|
transformation. This change makes the language more consistent in that <P>
|
|
regard.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
These changes address comments Yen #1 and Barrett #31.<P>
|
|
<P>
|
|
Pitman thinks all of these changes are a good idea.<P>
|
|
<P>
|
|
Barrett asked that we specify that:<P>
|
|
``logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> namestrings are valid <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> designators''<P>
|
|
Pitman hopes that the above satisfies the intent of that, but <P>
|
|
worries that since some logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> namestrings already were<P>
|
|
(e.g., "foo.bar") and just happened not to designate logical pathnames,<P>
|
|
this would be a confusing way to express the change. The change affects<P>
|
|
only those logical <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> namestrings which have a host name visible<P>
|
|
and for which there is no competing definition as a device, etc.<P>
|
|
The wording chosen above is intended to make an end run around this<P>
|
|
potential pitfall.<P>
|
|
<P>
|
|
Barmar says:<P>
|
|
Genera gets away with [HOST-COLON] because the Lisp parsing rules<P>
|
|
are consistent with those used by the Genera OS (hardly a<P>
|
|
coincidence). Users expect <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> parsing to be consistent within<P>
|
|
an OS, not subject to the choice of implementation language by the<P>
|
|
programmer.<P>
|
|
<P>
|
|
Consider a program that prompts the user for a file name and then parses<P>
|
|
it. The user will most likely use the normal <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> syntax for his<P>
|
|
system; on a PC that would be something like "c:\foo\bar.baz", and on<P>
|
|
VMS it might be "SYS$FOO:[BAR]BAZ.QUUX". Users of such programs should<P>
|
|
not be expected to know which programs are written in Lisp, which<P>
|
|
imposes different <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> parsing rules from all other programs on the<P>
|
|
OS.<P>
|
|
<P>
|
|
At the very least there needs to be a way for programs to force the CLtL<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> interpretation rules. Are you proposing that such programs<P>
|
|
should simply prepend a colon to the <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> read in? Considering<P>
|
|
that VMS has its own syntax for remote pathnames, what should be the<P>
|
|
result of (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-host"><B>pathname-host</B></A> ":HOST::DEV:[DIR]NAME.EXT") on a VMS system?<P>
|
|
The HOST-COLON proposal says that it should be the current default host,<P>
|
|
but VMS <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> interpretation implies that it should be something<P>
|
|
derived from "HOST".<P>
|
|
<P>
|
|
I'd like to hear some commentary from vendors and users of Lisps for<P>
|
|
VMS, Macs, and MS-DOS. Does CLOE use this <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> parsing strategy?<P>
|
|
Were users actually happy with it?<P>
|
|
<P>
|
|
<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|