Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Thu, 25 May 89 16:55 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Since you're the one who says that pathname manipulating programs are
> best written by getting namestrings and doing string processing on
> them, can you tell me how your programs know what syntax to expect
> in the namestrings?

I've never said anything like that and I think it's a crummy idea
anyway.  What I *have* said is that the only pathname operations that
a portable program can expect to do that make sense on all file
systems are:

1. Convert a (file-system specific) namestring to a pathname, and vice 
   versa.  The namestring need not appear as a literal in the program or
   be manipulated by doing string processing -- for example, you might 
   ask the user of the application to type in a namestring or supply 
   one as an argument.  That's what applications written in other
   programming languages such as C typically do, and there's really nothing
   wrong with it because users of the application certainly know what 
   kind of file system their files live on.

2. Test whether an object is a pathname.

3. Merge two pathnames to fill in missing components.  This is the whole
   point, in my view, of having pathnames at all, and where Common Lisp
   wins over C -- there is a library function to do this instead of
   programmers having to write their own, nonportable string-manipulation 
   code to do this. 

The point I've been trying to make is that any program that tries to
construct pathnames by providing component values directly is bound to
run into portability problems.  The file system may not support the
concept of a particular pathname component at all.  The file system
may impose limitations on the length of the component or on what
characters may appear in it.  (The perverse example I've cited before
is Cray's CTSS operating system, where files are limited to
6-character names, and there is no concept of hosts, devices,
directories, types, or versions.)  Components extracted from another
pathname may not make sense in a new pathname being constructed for a
different host.  That's why I think the right solution is really to
deprecate MAKE-PATHNAME. 

Specifying what *might* appear in a pathname component does not fix
the fundamental nonportability of MAKE-PATHNAME, because programmers
have no way of knowing whether an object which *might* be a valid
component actually *will be* a valid component in the environment in
which the application is run.

-Sandra
-------