PATHNAME-SYNTAX-ERROR-TIME
For example, on file systems which constrain pathname-types to be three letters or fewer, the type "LISP" is not valid. The question arises: when is this error detected?
In some implementations, the error might be detected while forming the pathname. That is, (MAKE-PATHNAME :TYPE "LISP") signals an error.
In some implementations, the error might be detected while forming the namestring. That is, (MAKE-PATHNAME :TYPE "LISP") succeeds, but (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) signals an error.
In some implementations, validity checking might be done only by the host operating system, so Lisp does not detect the error unless the operating system complains. For example, (MAKE-PATHNAME :TYPE "LISP") succeeds, and even (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) constructs a plausible looking pathname, but (OPEN (NAMESTRING (MAKE-PATHNAME :TYPE "LISP"))) fails.
In some implementations, Lisp might make `friendly' corrections to the pathname in order to form a namestring. For example, (MAKE-PATHNAME :TYPE "LISP") might succeed, but (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) might produce a namestring with an extension such as ".LIS" or ".LSP".
Similar issues might come up in file systems which don't allow wildcard pathnames. Is :WILD allowed in a name or type slot and then disallowed upon coercion to a pathname, or is :WILD complained about "up front"?
This phenomenon is a barrier to portability because if a program is debugged in an implementation that does, for example, NAMESTRING-time error checking, the programmer may be lulled into an expectation that it is acceptable to construct and manipulate invalid pathnames as long as the problem is caught before an attempt to call NAMESTRING is attempted. On the other hand, another programmer may debug his code in a Lisp which does early error checking of syntax and may assume that he is home free if the pathname gets constructed correctly.
MAKE-PATHNAME and MERGE-PATHNMES which construct new pathnames do plausibility checking of their arguments and signal an error rather than construct a pathname for which NAMESTRING would not produce a valid pathname.This would mean that fully constructed pathnames could reliably be converted to namestrings.
Implementations where this error checking is done later would have to be changed both to do it earlier, and to not make the unwarranted assumption that pathnames with no valid namestring representation are constructable.
Some code which expected an error, but expected it at a different time would have to be changed.
NAMESTRING (and related functions, such as ENOUGH-NAMESTRING or any internal functions that might be used in place of NAMESTRING by functions like OPEN and PROBE-FILE) to signal an error for pathnames which do not represent valid filenames in the designated file system.This would allow the construction of pathnames for the sole purpose of merging without causing what might seem to some as gratuitous errors.
Implementations where this error checking is done earlier would have to be changed both to do it later, and to not make the unwarranted assumption that any pathname has a valid namestring representation.
Some code which expected an error, but expected it at a different time would have to be changed.
Macsyma, for example, has encountered a need for "hostless" pathnames
(in merging). The concept makes no sense if every pathname must have
a namestring, because a pathname with no host cannot have a namestring.
However, if it's NAMESTRING's responsibility to signal an error, then
hostless pathnames are still useful for merging. Consider:
(MERGE-PATHNAMES (MAKE-PATHNAME :NAME "FRED") MARY)
This will override both the NAME and the HOST field of MARY because you
must currently have a host in every pathname. But if MAKE-PATHNAME did
not force the host, or if one could explicitly say :HOST NIL, then
such pathnames would be considerably more useful for merging.
Advise the editorial group to warn users clearly about this known source of program portability problems.
NAMESTRING will always succeed.PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but believes that anything is an improvement over ...:EXPLICITLY-VAGUE.
CL pathname functions were not adequate for use in Macsyma because they did not adequately represent to-be-merged-only pathnames (a feature used very extensively in Macsyma), because errors could be signalled at radically different times. To get around this, Pitman had to create a data structure in Macsyma called an MPATHNAME which was only trivially different than a PATHNAME but which made it possible to deal portably with this issue of when errors occurred and what kinds of errors occured. Unfortunately, since none of the CL functions worked on MPATHNAMEs, a whole series of functions, also only trivially different, had to be created: MAKE-MPATHNAME, MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE, MOPEN, WITH-MOPEN-FILE, etc.
------ Summary of CL-Cleanup discussion:
Most of the mail was endorsements for option PATHNAME-CREATION. Sandra brought up a tangential issue about truenames that eventually became a separate issue.
I think I'm the only person pushing NAMESTRING-COERCION. I strongly believe it is the right thing, and that PATHNAME-CREATION is suboptimal, based on problems that have struck me with existing CL pathname system. However, even PATHNAME-CREATION would be an improvement from a portability standpoint and I am probably not going to push it because there are compatibility issues on the side of PATHNAME-CREATION (many implementations do this already), and because there are more important issues for us to spend time on at the meeting.
[Please try to come prepared to vote yes on one or both of PATHNAME-CREATION or NAMESTRING-COERCION so we don't have to fall back on EXPLICITLY-VAGUE, which is a total loss for program portability. -kmp]