Issue: PATHNAME-COMPONENT-VALUE (version 1)

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

    Date: Tue, 21 Mar 89 19:21 EST
    From: Barry Margolin <barmar@Think.COM>

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

PATHNAME-COMPONENT-CASE addresses that; it's a separate issue.  I don't
know whether it's on the agenda for next week, but I hope it is.

    The only effect of the various pathname proposals is to extend the
    standard so that Symbolics's implementation conforms.  

Well, I certainly hope that with all the pathname proposals together, 
that is not the only effect!  The goal is to constrain the semantics
of pathnames enough to allow writing portable pathname-using programs,
so people will stop complaining that pathnames are a useless wart.

Maybe it was wrong to break it up into separate issues.

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

I think you're partly right here.  It was probably a mistake to try to
constrain the types of "structured" values, because there is nothing
that a portable program can do with a "structured" value that depends on
the type.

As for strings, the intent was that with PATHNAME-COMPONENT-CASE the
relation between the string and the name of the file is fully specified;
I guess that wasn't at all clear from the PATHNAME-COMPONENT-VALUE
writeup.  Similarly, with PATHNAME-SUBDIRECTORY-LIST the relation
between the list and the name of the directory is fully specified.

I see the proposal for PATHNAME-COMPONENT-CASE is rather stale, I'll
see if I can work up a version updated from the discussion tonight or
tomorrow.

    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.

Good point.