[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: PATHNAME-COMPONENT-VALUE (version 1)



This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase.  If I can't
write something as simple as

	(setq dp (pathname "/u/barmar/foo.lisp"))
	(namestring (make-pathname :name "bar" :defaults dp))

and have it mean the same thing in Lucid and Genera, what good is all
the rest?  Anyone trying to deal with pathnames portably needs to write
a set of wrapper functions, as Thinking Machines has.  Your proposals
don't really make this much easier.

The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms.  I have no problem
with this goal, but I think the approach is wrong.  What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values?  If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname.  I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL?  EQUAL?) host and device).  Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").

Background:

For those of you not familiar with Genera's mechanism for dealing with
pathname case (with which I can't really find fault, because it is the
only way to solve problem of name translation across OS types, but it
does result in portability problems), the above sequence results in
"/u/barmar/BAR.lisp" in Genera, but "/u/barmar/bar.lisp" in most Unix
implementations.  In Genera, the string arguments to MAKE-PATHNAME, and
the results of the PATHNAME-<component> functions, are not necessarily
in the same case the actual pathname, but in a format called
"interchange case".  In interchange format, uppercase represents the
preferred case for the OS, lowercase represents the opposite case, and
mixed case is used verbatim.  This allows you to do

	(make-pathname :name (pathname-name <unix-path>) :defaults <vms-path>)

and have the lowercase Unix name translated to an uppercase VMS name
automatically.

Unfortunately, I can't think of any way to solve this problem in the
standard without incorporating the whole concept of interchange case
into it.  There might not be too much opposition to it if we change the
design so that lowercase were used to represent the preferred case,
though.  How many uppercase-preferred systems are used much for Common
Lisp?  Are there any besides VAX/VMS?  (Uppercase-only systems such as
MS-DOS and case-insensitive systems such as Macintosh don't count, since
they can use uppercase or lowercase interchangeably without affecting
the semantics.)

By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.