I also dislike the conflation of the term "path" to mean both those
things.  I would like neither to use the term "path", but I used it
because it seemed conventional.

The current draft actually uses the term "search paths" (note the
plural) to mean its list of searched directories.  Prior versions of
this SRFI used the suffix "PATHS" (note the plural) for the environment
variable's name, but I was pressured into changing it to the
conventional "PATH" suffix.  I used plural "paths" because it's
consistent with the nature of a sense-2 thing being multiple sense-1
things which I was calling "path".

I'll gladly use better terms.  I like the term "list of searched
directories" for a sense-2 thing.  I don't think I like "file name" for
a sense-1 thing because such a thing can be a directory, but I like
"file/directory name".  Unfortunately, I suppose the environment
variable's name should continue to have the "PATH" suffix, otherwise
some people will freak-out :-)

(JTMI, I think Unixoid PATH should have been named
EXECUTABLE_SEARCH_LIST or something like that.  But that would not be
bizarrely truncated in true Unix/C tradition...)

--
: Derick
----------------------------------------------------------------

On Mon, 2010-01-11 at 20:05 -0800, Thomas Bushnell BSG wrote:
> This is a more minor concern than my previous note, but also important.
>
> The srfi uses the term "path" in mutual confusing ways.  Richard
> Stallman impressed upon me--and I think he's quite right--that Unix has
> traditionally used the word "path" in two quite different senses.
>
> Sense one means by a path a sequence of directory names, separated on
> Unix with a slash.  When we say that "/usr/include/stdio.h" is a path,
> this is sense 1.
>
> Sense two means a list of sense-one paths, often written with a colon as
> separator between them, identifing a list of directories to search to
> find a file.  When we say that your PATH
> is /bin:/usr/bin:/usr/local/bin, this is a sense-2 path.
>
> The GNU Project has abandoned this systematic ambiguity and never uses
> the word "path" in sense-1, sense there is the perfectly good "filename"
> already.  I believe that Posix as well never uses "path" in sense-1, but
> I can't recall exactly.  (Historically, "filename" referred in Unix to
> the entry in a specific directory, but those days are gone.)
>
> The srfi introduces the concept of a "library file path", which is a
> sense-1 path, and which is essentially a specification of the format of
> an r5rs/r6rs "filename", and a re-specification of a Unix filename.
>
> Can I request that the srfi drop the attempt to call filenames "path
> names", and stick to "path" specifically in the context of a search
> path?
>
> Thomas