Re: Issue: PATHNAME-COMPONENT-CASE (version 4)

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

I have a number of comments on this writeup, and some general comments
on the issue it's trying to deal with.

First the specific ones.

>  Issues of alphabetic case in pathnames are a major source of problems.

I'd say it's a much less "major" source of problems than issues
relating to what characters may appear in pathname components and the
length of various components.

>   There are two kinds of pathname case portability problems: moving
>   programs from one Common Lisp to another, and moving pathname component
>   values from one file system to another.  To solve the first problem, all
>   Common Lisp implementations that support a particular file system must
>   use compatible representations for pathname component values.  To solve
>   the second problem, there must be a common representation for the least
>   common denominator pathname component values that exist on all
>   interesting file systems.

Since this proposal doesn't do either of these two things, I don't 
understand what this paragraph is doing in this writeup.

>   :COMMON means those strings follow this common convention:
>     - all uppercase means to use a file system's customary case.
>     - all lowercase means to use the opposite of the customary case.
>     - mixed case represents itself.
>   The second and third bullets exist so that translation from local to
>   common and back to local is information-preserving.

I don't understand the motivation for this.  There is no way to
specify a pathname component that is literally all uppercase or all
lowercase.

>   VAX/VMS is upper-case-only, so it translates common to local by upcasing,
>   and translates local to common with no change.

VAX/VMS is case-insensitive but its canonical case is uppercase.  Its
file system primitives are perfectly capable of dealing with lowercase
namestrings -- it's just that if you ever ask it for the name of a
file, it will return it in uppercase.

Now for the more general comments.  I think that the :CASE :COMMON
option is pretty much useless because it doesn't handle the situation
where you want the pathname component kept in exactly the case you
specified it.  I can't imagine any reason why I would want to specify
a pathname component in the *opposite* of canonical case, plus if I
did I could get it by inverting the canonical case. 

I'd suggest trashing the current proposal and instead adding a
:CANONICALIZE keyword argument to MAKE-PATHNAME and PARSE-NAMESTRING. 

A value of T indicates that the implementation is free to canonicalize
the representation of the pathname component in any way that is
appropriate for the particular host.  This might include things like
truncation and performing some kind of filtering or translation on
invalid characters, and even expansion of logical names (on VMS), as
well as case conversion. 

A value of NIL indicates that the pathname components are to be
treated as literals.  I think it would be a good idea to require an
error to be signalled in situations where a component is not a
legitimate value. 

I think implementations should be permitted to assign meanings for
other values of this argument. 

-Sandra
-------