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


Status:	      Accepted, as amended, Jan 89 X3J13

Forum: Cleanup


Forum: Cleanup

References: File System Interface (pp409-427)

Category: CHANGE

Edit history: 27-Dec-88, Version 1 by Pitman

17-Mar-89, Version 2 by Masinter (as amended)


Problem Description:

In some file systems, it is inappropriate to represent particular

pathname components, either all the time or in some specialized


- Unix pathnames never have a version field.

- In some file systems, specifying a device and a directory means

something very different than specifying the device alone,

particularly when the device is a "logical device" that may

already imply a directory.

- Some Unix pathnames have types and others do not. For example,

it is possible to make files named "foo." and "foo" which are

distinct. CLtL (p412) specifies that the type is ``always a

string, NIL, or :WILD.'' This description is too restrictive

to be practical in this case. One of these (usually the former)

can get a type of "" but it is not clear how to represent the

other. If NIL is used, merging primitives cannot detect that the

field is filled and should not be merged against.

- ITS pathnames have either a version or a type, but never both.

"JOE;FILE 32" has a directory, a name, and a version.

"JOE;FILE TEXT" has a directory, a name, and a type.

"JOE;FILE TEXT 32" is not a possible ITS filename.


Permit :UNSPECIFIC as a value of any field of a pathname,


VERSION field of a pathname, for file systems in which it makes sense.

The results of supplying :UNSPECIFIC to a file system for which

it does not make sense are undefined.

When a pathname is converted to a namestring, NIL and :UNSPECIFIC

are treated as if the field were empty. That is, they both cause the

component not to appear in the string.

When merging, however, only a NIL value for a component will be

replaced with the default for that component, while :UNSPECIFIC

will be left alone as if the field were filled.

Portable programs should expect to find :UNSPECIFIC in the device,

directory, type, or version field in some implementations.

Portable programs should not explicitly place :UNSPECIFIC in any

field, since that it might not be permitted in some situations,

but portable programs may sometimes do so implicitly.

Test Case:

;; #1: Non-portable code. This may signal an error in some

;; implementations where an unspecific type makes no sense.


;; #2: In this example, assume a Unix file system.


=> ""






;; #3: In this example, assume an ITS file system.











;; Note: It is not the intent of this proposal to actually legislate

;; the canonical representation of Unix pathnames "foo." and "foo",

;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably

;; be done, but under separate cover. The above examples are intended

;; only to demonstrate how this proposal will permit the representation

;; of pathnames not usefully representable under CLtL.


This is, by necessity, current practice in some implementations


Current Practice:

Symbolics Genera uses a file types and versions of :UNSPECIFIC on

Unix and ITS file systems, for example.

Cost to Implementors:

None. No change to any implementation is forced.

Some implementations which already do this are legitimized.

Some implementations which use a non-standard token other than

:UNSPECIFIC to implement this functionality would want to switch

to use :UNSPECIFIC so that portable programs could expect it.

Cost to Users:

Some programs which manipulate pathnames should be updated to expect

:UNSPECIFIC in the type fields in some situations.

Any program which doesn't already expect :UNSPECIFIC is already not really

portable, however, given that some implementations have been forced to

go beyond the standard in order to represent all possible pathnames.

Cost of Non-Adoption:

Some implementations would be unable to both represent all possible

pathnames in a rational way and at the same time to conform to the

standard. Such an inability would seriously jeopardize the usefulness

of Common Lisp in the design of serious programs.


Some programs involving pathnames would be more portable.


Sweeping a hairy situation under the rug doesn't make it go away.

This change makes things appear less simple, but since in reality

they were less simple, it is effectively a simplification of the

correspondence between the CL model and reality.



This feature existed (for types) in the Colander draft edition of

CLtL, but was removed for the Laser edition. The following text is

excerpted from the Colander edition, p259:

``??? Query: Is :unspecific really needed over and above nil?

``A component of a pathname can also be the keyword

:UNSPECIFIC. This means that the component has been explicitly

determined not to be there, as opposed to be missing. One way

this can occur is with generic pathnames, which refer not to

a file but to a whole family of files. The version, and usually

the type, of a generic pathname are :unspecific. Another way

:unspecific is used to represent components that are not simply

supported by a file system. When a pathname is converted to a

namestring, nil and :unspecific both cause the component not to

appear in the string. When merging, however, a nil value for

a component will be replaced with the default for that

component, while :unspecific will be left alone.''

"The stuff about generic pathnames in the discussion section

was brain damage and may have lead to the confusion that caused

:unspecific to be dropped from Common Lisp. Only the stuff about

components not supported by a file system makes sense."

[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.