239 lines
15 KiB
HTML
239 lines
15 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-SYNTAX-ERROR-TIME 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/iss264_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss265.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss266_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/iss264_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss265.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss266_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue PATHNAME-SYNTAX-ERROR-TIME Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Issue:</B> <A HREF="iss265.htm">PATHNAME-SYNTAX-ERROR-TIME</A><P>
|
||
|
|
<B>References:</B> File System Interface (pp409-427)<P>
|
||
|
|
<B>Category:</B> CLARIFICATION<P>
|
||
|
|
<B>Edit history:</B> 07-Jul-88, Version 1 by Pitman<P>
|
||
|
|
<B>Status:</B> For Internal Discussion<P>
|
||
|
|
<P>
|
||
|
|
<B>Problem Description:<P>
|
||
|
|
</B><P>
|
||
|
|
There exist conceivable pathnames for which there is no valid mapping in a<P>
|
||
|
|
particular implementation. CLtL is not clear about the time at which this<P>
|
||
|
|
error might be detected.<P>
|
||
|
|
<P>
|
||
|
|
For example, on file systems which constrain pathname-types to be three<P>
|
||
|
|
letters or fewer, the type "LISP" is not valid. The question arises: when<P>
|
||
|
|
is this error detected?<P>
|
||
|
|
<P>
|
||
|
|
In some implementations, the error might be detected while forming the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. That is, (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP") signals an error.<P>
|
||
|
|
<P>
|
||
|
|
In some implementations, the error might be detected while forming the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>. That is, (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP") succeeds, but<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP")) signals an error.<P>
|
||
|
|
<P>
|
||
|
|
In some implementations, validity checking might be done only by the host<P>
|
||
|
|
operating system, so Lisp does not detect the error unless the operating<P>
|
||
|
|
system complains. For example, (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP") succeeds,<P>
|
||
|
|
and even (<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP")) constructs a plausible<P>
|
||
|
|
looking <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, but (<A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> (<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP"))) fails.<P>
|
||
|
|
<P>
|
||
|
|
In some implementations, Lisp might make `friendly' corrections to the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> in order to form a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>. For example,<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP") might succeed, but <P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :TYPE "LISP")) might produce a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> with<P>
|
||
|
|
an extension such as ".LIS" or ".LSP".<P>
|
||
|
|
<P>
|
||
|
|
Similar issues might come up in file systems which don't allow wildcard<P>
|
||
|
|
pathnames. Is :WILD allowed in a name or type slot and then disallowed<P>
|
||
|
|
upon coercion to a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, or is :WILD complained about "up front"?<P>
|
||
|
|
<P>
|
||
|
|
This phenomenon is a barrier to portability because if a program is<P>
|
||
|
|
debugged in an implementation that does, for example, NAMESTRING-time<P>
|
||
|
|
error checking, the programmer may be lulled into an expectation that<P>
|
||
|
|
it is acceptable to construct and manipulate invalid pathnames as long<P>
|
||
|
|
as the problem is caught before an attempt to call <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> is<P>
|
||
|
|
attempted. On the other hand, another programmer may debug his code in<P>
|
||
|
|
a Lisp which does early error checking of syntax and may assume that <P>
|
||
|
|
he is home free if the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> gets constructed correctly.<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):<P>
|
||
|
|
</B><P>
|
||
|
|
Clarify that operations such as <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> and MERGE-PATHNMES which<P>
|
||
|
|
construct new pathnames do plausibility checking of their arguments<P>
|
||
|
|
and signal an error rather than construct a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> for which <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A><P>
|
||
|
|
would not produce a valid <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
Rationale:<P>
|
||
|
|
<P>
|
||
|
|
This would identify clearly to the programmer where he should expect an<P>
|
||
|
|
error to be signalled for a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
This would mean that fully constructed pathnames could reliably<P>
|
||
|
|
be converted to namestrings.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Implementors:<P>
|
||
|
|
<P>
|
||
|
|
Some implementors, especially those which rely on the operating system<P>
|
||
|
|
to be the sole authority on <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> syntax, might have to introduce<P>
|
||
|
|
some new syntax-checking facilities.<P>
|
||
|
|
<P>
|
||
|
|
Implementations where this error checking is done later would have to be<P>
|
||
|
|
changed both to do it earlier, and to not make the unwarranted assumption<P>
|
||
|
|
that pathnames with no valid <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> representation are constructable.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Users:<P>
|
||
|
|
<P>
|
||
|
|
The ability to represent non-viable pathnames for the purpose of merging<P>
|
||
|
|
would be lost. This feature was not portably available, but was available<P>
|
||
|
|
in some operating systems.<P>
|
||
|
|
<P>
|
||
|
|
Some code which expected an error, but expected it at a different time<P>
|
||
|
|
would have to be changed.<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):<P>
|
||
|
|
</B><P>
|
||
|
|
Clarify that it was valid to create a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> which could not be<P>
|
||
|
|
converted to a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>. Require <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> (and related functions,<P>
|
||
|
|
such as <A REL=DEFINITION HREF="../Body/f_namest.htm#enough-namestring"><B>ENOUGH-NAMESTRING</B></A> or any internal functions that might be used<P>
|
||
|
|
in place of <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> by functions like <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> and <A REL=DEFINITION HREF="../Body/f_probe_.htm#probe-file"><B>PROBE-FILE</B></A>) to signal<P>
|
||
|
|
an error for pathnames which do not represent valid filenames in the<P>
|
||
|
|
designated file system.<P>
|
||
|
|
<P>
|
||
|
|
Rationale:<P>
|
||
|
|
<P>
|
||
|
|
This would identify clearly to the programmer where he should expect an<P>
|
||
|
|
error to be signalled for a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
This would allow the construction of pathnames for the sole purpose of<P>
|
||
|
|
merging without causing what might seem to some as gratuitous errors.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Implementors:<P>
|
||
|
|
<P>
|
||
|
|
Implementors who rely on the operating system to be the sole authority<P>
|
||
|
|
on <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> syntax, might have to introduce some new syntax-checking<P>
|
||
|
|
facilities.<P>
|
||
|
|
<P>
|
||
|
|
Implementations where this error checking is done earlier would have to<P>
|
||
|
|
be changed both to do it later, and to not make the unwarranted<P>
|
||
|
|
assumption that any <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> has a valid <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A> representation.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Users:<P>
|
||
|
|
<P>
|
||
|
|
Early error checking of faulty pathnames would be lost.<P>
|
||
|
|
<P>
|
||
|
|
Some code which expected an error, but expected it at a different time<P>
|
||
|
|
would have to be changed.<P>
|
||
|
|
<P>
|
||
|
|
Benefits:<P>
|
||
|
|
<P>
|
||
|
|
Macsyma, for example, has encountered a need for "hostless" pathnames<P>
|
||
|
|
(in merging). The concept makes no sense if every <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> must have<P>
|
||
|
|
a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>, because a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> with no host cannot have a <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>namestring</B></A>.<P>
|
||
|
|
However, if it's <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A>'s responsibility to signal an error, then<P>
|
||
|
|
hostless pathnames are still useful for merging. Consider:<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A> (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :NAME "FRED") MARY)<P>
|
||
|
|
This will override both the NAME and the HOST field of MARY because you<P>
|
||
|
|
must currently have a host in every <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. But if <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> did<P>
|
||
|
|
not force the host, or if one could explicitly say :HOST <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, then<P>
|
||
|
|
such pathnames would be considerably more useful for merging.<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):<P>
|
||
|
|
</B><P>
|
||
|
|
Clarify that we were unable to reach agreement on this issue and that<P>
|
||
|
|
the time at which this error detection occurs is not well-specified.<P>
|
||
|
|
<P>
|
||
|
|
Advise the editorial group to warn users clearly about this known source<P>
|
||
|
|
of program portability problems.<P>
|
||
|
|
<P>
|
||
|
|
Rationale:<P>
|
||
|
|
<P>
|
||
|
|
This implements the status quo.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Implementors:<P>
|
||
|
|
<P>
|
||
|
|
None.<P>
|
||
|
|
<P>
|
||
|
|
Cost to Users:<P>
|
||
|
|
<P>
|
||
|
|
No existing code must be modified, but there is an ongoing cost<P>
|
||
|
|
associated with providing error checking at multiple points in a<P>
|
||
|
|
program because implementations disagree as to where an error<P>
|
||
|
|
might be signalled. In some cases, the effects of having to handle<P>
|
||
|
|
this in multiple places may cause unpleasant modularity violations.<P>
|
||
|
|
<P>
|
||
|
|
<B>Test Case:<P>
|
||
|
|
</B><P>
|
||
|
|
See problem description.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current Practice:<P>
|
||
|
|
</B><P>
|
||
|
|
Symbolics Genera signals an error at <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> construction time if a<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> will be invalid. Once a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> is successfully constructed,<P>
|
||
|
|
it can generally be assumed that <A REL=DEFINITION HREF="../Body/f_namest.htm#namestring"><B>NAMESTRING</B></A> will always succeed.<P>
|
||
|
|
<P>
|
||
|
|
<B>Aesthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
Making this more well-defined would cause a definite aesthetic<P>
|
||
|
|
improvement to some programs.<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
Pitman prefers PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but<P>
|
||
|
|
believes that anything is an improvement over ...:EXPLICITLY-VAGUE.<P>
|
||
|
|
<P>
|
||
|
|
CL <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> functions were not adequate for use in Macsyma because<P>
|
||
|
|
they did not adequately represent to-be-merged-only pathnames (a<P>
|
||
|
|
feature used very extensively in Macsyma), because errors could be<P>
|
||
|
|
signalled at radically different times. To get around this, Pitman<P>
|
||
|
|
had to create a data <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> in Macsyma called an MPATHNAME which<P>
|
||
|
|
was only trivially different than a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> but which made it<P>
|
||
|
|
possible to deal portably with this issue of when errors occurred<P>
|
||
|
|
and what kinds of errors occured. Unfortunately, since none of the<P>
|
||
|
|
CL functions worked on MPATHNAMEs, a whole series of functions,<P>
|
||
|
|
also only trivially different, had to be created: MAKE-MPATHNAME,<P>
|
||
|
|
MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE, <P>
|
||
|
|
MOPEN, WITH-MOPEN-FILE, etc.<P>
|
||
|
|
<P>
|
||
|
|
------<P>
|
||
|
|
Summary of CL-Cleanup discussion:<P>
|
||
|
|
<P>
|
||
|
|
Most of the mail was endorsements for option PATHNAME-CREATION.<P>
|
||
|
|
Sandra brought up a tangential issue about truenames that eventually<P>
|
||
|
|
became a separate issue.<P>
|
||
|
|
<P>
|
||
|
|
I think I'm the only person pushing NAMESTRING-COERCION. I strongly<P>
|
||
|
|
believe it is the right thing, and that PATHNAME-CREATION is suboptimal,<P>
|
||
|
|
based on problems that have struck me with existing CL <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> system.<P>
|
||
|
|
However, even PATHNAME-CREATION would be an improvement from a<P>
|
||
|
|
portability standpoint and I am probably not going to push it because<P>
|
||
|
|
there are compatibility issues on the side of PATHNAME-CREATION (many<P>
|
||
|
|
implementations do this already), and because there are more important<P>
|
||
|
|
issues for us to spend time on at the meeting.<P>
|
||
|
|
<P>
|
||
|
|
[Please try to come prepared to vote yes on one or both of<P>
|
||
|
|
PATHNAME-CREATION or NAMESTRING-COERCION so we don't have to fall back<P>
|
||
|
|
on EXPLICITLY-VAGUE, which is a total loss for program portability.<P>
|
||
|
|
-kmp]<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>
|