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

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

    Date: Thu, 25 May 89 12:08:59 MDT
    From: 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.

Let's not quibble about this, it's unproductive.

    >   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.

This proposal does the alphabetic case portion of both things.  Do you
think it doesn't?  Or are you saying that you would prefer to see all the
pathname issues rolled into one omnibus proposal?  I was hesitant about
not allowing people the chance to vote separately on each portion of the
pathname stuff.

    >   :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.

That is correct, in the :COMMON representation there is no way to say
those things.  That's because those are not portable concepts.  You use
the :LOCAL representation to do things like that.

Things would be a lot simpler if :COMMON representation was monocase,
which is the least common denominator.  The problem with that would be
that in some file systems (e.g. Unix) there would be many pathnames
that could not be represented in :COMMON representation at all.  Rather
than signal an error when such a pathname is encountered, it seems better
to assign otherwise unused characters (the lowercase letters) to represent
such pathnames.  Perhaps the proposal should be reworked to present things
in these terms?

    >   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.

That's precisely what upper-case-only means.  Sorry about the
terminological unclarity.  Upper-case-only wasn't intended to mean
that it signals an error if you give it a lowercase letter; I don't
think we want any file systems like that in Common Lisp; if the file
system doesn't upcase, the Lisp interface to it should, rather than
signalling an error if it can't handle lower case.  Should I augment
the proposal with more definitions of terminology?

Note how VAX/VMS differs from other case-insensitive systems such
as the Macintosh, where file lookup is case-insensitive but if you
ask for the name of a file it will give it back in the same alphabetic
case in which you created it.

    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.  

That's what :CASE :LOCAL is for.  :CASE :COMMON is for portable programs
that want to conform to the local conventions of the local file system
rather than imposing their own conventions.  Not all programs want to do
that, but I would hardly characterize that as useless.

		   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 can't imagine any reason either.  See above for the motivation for this.

    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. 

This could be a useful feature in its own right, but note that it is
no help at all for retrieving pathname components in a form that is
independent of the local file system, which is what the :CASE argument
to the PATHNAME-xxx accessors proposed here is for.  I would encourage
you to write up your proposal in more detail.  I think you will find
some difficulties in defining exactly what is an invalid character
(for example, is a character invalid if this file system uses it as
a wildcard character but other file systems use it as an ordinary
character?) and some of the other specifics.  Also it would be helpful
to see your proposal complete with rationale, examples, costs, and
benefits.