Issue: PATHNAME-CANONICAL-TYPE

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Larry suggests a simpler proposal than Kent's.  Here is some background
on pathname canonical types in general:

There are three purposes served by pathname canonical types:

(1) Construction.  There is currently no portable way to construct a
pathname that follows local file naming conventions.  For example, given
a program named "foo", we'd like to construct the conventional names for
its source and compiled files.  These will be "foo.l" and "foo.b" on one
system, "FOO.LSP" and "FOO.BIN" on another system, and "foo.lisp" and
"foo.ibin" on a third system.

More generally, we would like to be able to access naming conventions
for many types of files, not just Lisp source and compiled Lisp.  A
simplifying assumption is that all naming conventions affect only the
type field.  Thus a facility to translate canonical types into actual
types is sufficient.  Another assumption is that a given file system
always uses the same actual type for a given class of file; Symbolics
pathname canonical types are more general than this, but that is not
being proposed here, as it was primarily useful only in connection with
a transition between different releases of Unix, an application too
specialized to be enshrined in Common Lisp.

We would also like users to be able to define new classes of files of
their own, with associated file-system-dependent naming conventions.
For example, if I write a portable `defsystem', I would use a unique
naming convention for the file in which it stores its configuration
database.  The naming convention might not use the same string on every
file system, so it should be a canonical type.

(2) Recognition.  There is currently no portable way to classify a file
 from its pathname.  If I write a portable editor, I would like to be
able to recognize the syntax of a program source file from its pathname
type field (Lisp, C, Ada, etc.)  The same table of local file naming
conventions used in part 1 can be accessed in reverse to translate an
actual type to a canonical type.  The editor can then look up the
canonical type in a table of known languages.

There is a tension here between two goals when there are subclasses of
files.  Consider two systems that can cross-compile for each other.
This clearly involves two canonical types for compiled Lisp files.
Should the canonical type reflect the system for which the file was
compiled, so that the canonical type of a particular file has the same
value in both systems?  Or should both systems use the same canonical
type for files compiled to be loaded locally, so that the canonical type
of a particular usage of a file has the same value in both systems?

(3) Translation.  There is currently no portable way to translate a
pathname written in the file naming conventions of one file system into
a pathname written in the file naming conventions of a different file
system.  A trivial use for this is cross-host pathname defaulting and
merging in a heterogeneous network, e.g. so a portable copy file command
can default the output file name intelligently.  A much more important
use is in logical pathnames (logical pathnames are a universal file
system that is mapped into the locally available file system through
site-dependent translations; this is primarily useful in software
distribution), where it is necessary to translate accurately between
logical pathname file naming conventions and local file naming
conventions.  The table of file naming conventions used in part 1 can be
accessed in reverse to identify the canonical type of a logical
pathname, and then accessed forwards to translate to the actual type to
be used on the local file system.

Whether we want Common Lisp to support these three features in a
portable fashion is of course a matter of policy.  Omitting any or all
of the features does not make the language unusable, it just means two
things: Users writing programs not intended to be portable will build
the local conventions directly into their programs, causing problems
later if they change their minds about portability.  Every user writing
a portable program that needs such capabilities has to implement them
himself, or obtain them from some supplier other than the Common Lisp
language, which will produce a small non-portable appendage to the
program that has to be redone for each port.

Critique of the proposals:

Larry's proposal addresses only the first paragraph of part 1.  It
does not allow user definition of file naming conventions and does
not support recognition or translation at all.

Kent's proposal addresses part 2 and the first paragraph of part 1.
It probably extends trivially to address part 3 as well, by adding
a statement that MERGE-PATHNAMES uses canonical types to merge
the type field.

As noted in the discussion section of the proposal, I would prefer
a proposal that addressed all three parts, which would require a
way to name file system types.  We could follow the standard defined
by the Internet Domain Name system.