[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: PATHNAME-COMPONENT-VALUE (version 1)
- To: Barry Margolin <barmar@Think.COM>
- Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Tue, 21 Mar 89 20:48 EST
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: <19890322002110.7.BARMAR@OCCAM.THINK.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
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
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.