207 lines
13 KiB
HTML
207 lines
13 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-UNSPECIFIC-COMPONENT 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/iss265_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss266.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss267_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/iss265_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss266.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss267_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-UNSPECIFIC-COMPONENT Writeup</H2>
|
|
|
|
<PRE><B>Status:</B> Accepted, as amended, Jan 89 X3J13<P>
|
|
<B>Forum:</B> Cleanup<P>
|
|
<B>Issue:</B> <A HREF="iss266.htm">PATHNAME-UNSPECIFIC-COMPONENT</A><P>
|
|
<B>Forum:</B> Cleanup<P>
|
|
<B>References:</B> File System Interface (pp409-427)<P>
|
|
<B>Category:</B> CHANGE<P>
|
|
<B>Edit history:</B> 27-Dec-88, Version 1 by Pitman<P>
|
|
17-Mar-89, Version 2 by Masinter (as amended)<P>
|
|
Subsumes: Issue PATHNAME-TYPE-UNSPECIFIC<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
In some file systems, it is inappropriate to represent particular<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components, either all the time or in some specialized <P>
|
|
circumstance.<P>
|
|
<P>
|
|
- Unix pathnames never have a version field.<P>
|
|
<P>
|
|
- In some file systems, specifying a device and a directory means<P>
|
|
something very different than specifying the device alone, <P>
|
|
particularly when the device is a "logical device" that may<P>
|
|
already imply a directory.<P>
|
|
<P>
|
|
- Some Unix pathnames have types and others do not. For example,<P>
|
|
it is possible to make files named "foo." and "foo" which are<P>
|
|
distinct. CLtL (p412) specifies that the type is ``always a<P>
|
|
string, <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, or :WILD.'' This description is too restrictive<P>
|
|
to be practical in this case. One of these (usually the former)<P>
|
|
can get a type of "" but it is not clear how to represent the<P>
|
|
other. If <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> is used, merging primitives cannot detect that the<P>
|
|
field is filled and should not be merged against. <P>
|
|
<P>
|
|
- ITS pathnames have either a version or a type, but never both.<P>
|
|
"JOE;FILE 32" has a directory, a name, and a version.<P>
|
|
"JOE;FILE TEXT" has a directory, a name, and a type.<P>
|
|
"JOE;FILE TEXT 32" is not a possible ITS filename.<P>
|
|
<P>
|
|
<B>Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):<P>
|
|
</B><P>
|
|
Permit :UNSPECIFIC as a value of any field of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>,<P>
|
|
including the HOST, DEVICE, <A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A>, NAME, <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A>, or<P>
|
|
VERSION field of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, for file systems in which it makes sense.<P>
|
|
<P>
|
|
The results of supplying :UNSPECIFIC to a file system for which<P>
|
|
it does not make sense are undefined.<P>
|
|
<P>
|
|
When a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is converted to a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>, <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> and :UNSPECIFIC<P>
|
|
are treated as if the field were empty. That is, they both cause the<P>
|
|
component not to appear in the string.<P>
|
|
<P>
|
|
When merging, however, only a <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> value for a component will be<P>
|
|
replaced with the default for that component, while :UNSPECIFIC<P>
|
|
will be left alone as if the field were filled.<P>
|
|
<P>
|
|
Portable programs should expect to find :UNSPECIFIC in the device,<P>
|
|
directory, type, or version field in some implementations.<P>
|
|
<P>
|
|
Portable programs should not explicitly place :UNSPECIFIC in any<P>
|
|
field, since that it might not be permitted in some situations,<P>
|
|
but portable programs may sometimes do so implicitly.<P>
|
|
<P>
|
|
<B>Test Case:<P>
|
|
</B><P>
|
|
;; #1: Non-portable code. This may signal an error in some<P>
|
|
;; implementations where an unspecific type makes no sense.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE :UNSPECIFIC) ;not portable<P>
|
|
<P>
|
|
;; #2: In this example, assume a Unix file system.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "foo."))<P>
|
|
=> ""<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "foo"))<P>
|
|
=> :UNSPECIFIC<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> (<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "foo")<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "BAR")))<P>
|
|
=> :UNSPECIFIC<P>
|
|
<P>
|
|
;; #3: In this example, assume an ITS file system.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((P (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "FOO 32")))<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> P) (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-version"><B>PATHNAME-VERSION</B></A> P)))<P>
|
|
=> (:UNSPECIFIC 32)<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((P (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "FOO TEXT")))<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> P) (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-version"><B>PATHNAME-VERSION</B></A> P)))<P>
|
|
=> ("TEXT" :UNSPECIFIC)<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((P (<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "FOO 32")<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "FOO TEXT"))))<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-type"><B>PATHNAME-TYPE</B></A> P) (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-version"><B>PATHNAME-VERSION</B></A> P)))<P>
|
|
=> (:UNSPECIFIC 32)<P>
|
|
<P>
|
|
;; Note: It is not the intent of this proposal to actually legislate<P>
|
|
;; the canonical representation of Unix pathnames "foo." and "foo",<P>
|
|
;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably<P>
|
|
;; be done, but under separate cover. The above examples are intended<P>
|
|
;; only to demonstrate how this proposal will permit the representation<P>
|
|
;; of pathnames not usefully representable under CLtL.<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This is, by necessity, current practice in some implementations<P>
|
|
already.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Symbolics Genera uses a file types and versions of :UNSPECIFIC on<P>
|
|
Unix and ITS file systems, for example.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
None. No change to any implementation is forced.<P>
|
|
<P>
|
|
Some implementations which already do this are legitimized.<P>
|
|
<P>
|
|
Some implementations which use a non-standard token other than <P>
|
|
:UNSPECIFIC to implement this functionality would want to switch<P>
|
|
to use :UNSPECIFIC so that portable programs could expect it.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
Some programs which manipulate pathnames should be updated to expect<P>
|
|
:UNSPECIFIC in the type fields in some situations.<P>
|
|
<P>
|
|
Any program which doesn't already expect :UNSPECIFIC is already not really<P>
|
|
portable, however, given that some implementations have been forced to<P>
|
|
go beyond the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> in order to represent all possible pathnames.<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
Some implementations would be unable to both represent all possible <P>
|
|
pathnames in a rational way and at the same time to conform to the<P>
|
|
<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>. Such an inability would seriously jeopardize the usefulness<P>
|
|
of Common Lisp in the design of serious programs.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Some programs involving pathnames would be more portable.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Sweeping a hairy situation under the rug doesn't make it go away.<P>
|
|
This change makes things appear less simple, but since in reality<P>
|
|
they were less simple, it is effectively a simplification of the<P>
|
|
correspondence between the CL model and reality.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.<P>
|
|
<P>
|
|
This feature existed (for types) in the Colander draft edition of<P>
|
|
CLtL, but was removed for the Laser edition. The following text is<P>
|
|
excerpted from the Colander edition, p259:<P>
|
|
<P>
|
|
``??? Query: Is :unspecific really needed over and above nil?<P>
|
|
<P>
|
|
``A component of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> can also be the keyword<P>
|
|
:UNSPECIFIC. This means that the component has been explicitly<P>
|
|
determined not to be there, as opposed to be missing. One way<P>
|
|
this can occur is with generic pathnames, which refer not to<P>
|
|
a file but to a whole family of files. The version, and usually<P>
|
|
the type, of a generic <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> are :unspecific. Another way<P>
|
|
:unspecific is used to represent components that are not simply<P>
|
|
supported by a file system. When a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is converted to a<P>
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>, nil and :unspecific both cause the component not to<P>
|
|
appear in the string. When merging, however, a nil value for<P>
|
|
a component will be replaced with the default for that<P>
|
|
component, while :unspecific will be left alone.''<P>
|
|
<P>
|
|
"The stuff about generic pathnames in the discussion section<P>
|
|
was brain damage and may have lead to the confusion that caused<P>
|
|
:unspecific to be dropped from Common Lisp. Only the stuff about<P>
|
|
components not supported by a file system makes sense."<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>
|