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


Issue PATHNAME-SYNTAX-ERROR-TIME Writeup

Issue:        PATHNAME-SYNTAX-ERROR-TIME

References: File System Interface (pp409-427)

Category: CLARIFICATION

Edit history: 07-Jul-88, Version 1 by Pitman

Status: For Internal Discussion

Problem Description:

There exist conceivable pathnames for which there is no valid mapping in a

particular implementation. CLtL is not clear about the time at which this

error might be detected.

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.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):

Clarify that operations such as 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.

Rationale:

This would identify clearly to the programmer where he should expect an

error to be signalled for a pathname.

This would mean that fully constructed pathnames could reliably

be converted to namestrings.

Cost to Implementors:

Some implementors, especially those which rely on the operating system

to be the sole authority on pathname syntax, might have to introduce

some new syntax-checking facilities.

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.

Cost to Users:

The ability to represent non-viable pathnames for the purpose of merging

would be lost. This feature was not portably available, but was available

in some operating systems.

Some code which expected an error, but expected it at a different time

would have to be changed.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):

Clarify that it was valid to create a pathname which could not be

converted to a namestring. Require 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.

Rationale:

This would identify clearly to the programmer where he should expect an

error to be signalled for a pathname.

This would allow the construction of pathnames for the sole purpose of

merging without causing what might seem to some as gratuitous errors.

Cost to Implementors:

Implementors who rely on the operating system to be the sole authority

on pathname syntax, might have to introduce some new syntax-checking

facilities.

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.

Cost to Users:

Early error checking of faulty pathnames would be lost.

Some code which expected an error, but expected it at a different time

would have to be changed.

Benefits:

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.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):

Clarify that we were unable to reach agreement on this issue and that

the time at which this error detection occurs is not well-specified.

Advise the editorial group to warn users clearly about this known source

of program portability problems.

Rationale:

This implements the status quo.

Cost to Implementors:

None.

Cost to Users:

No existing code must be modified, but there is an ongoing cost

associated with providing error checking at multiple points in a

program because implementations disagree as to where an error

might be signalled. In some cases, the effects of having to handle

this in multiple places may cause unpleasant modularity violations.

Test Case:

See problem description.

Current Practice:

Symbolics Genera signals an error at pathname construction time if a

pathname will be invalid. Once a pathname is successfully constructed,

it can generally be assumed that NAMESTRING will always succeed.

Aesthetics:

Making this more well-defined would cause a definite aesthetic

improvement to some programs.

Discussion:

Pitman prefers 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]


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