In my opinion, the use of "search path" is unproblematic, provided it
isn't nestled together with sense-1 paths.  I would just call those
"filenames" and say straight out that this srfi establishes a syntax for
filenames.  (In Unix--and let's be clear, this is really a Unix
srfi--directories *are* files, or they were, before Unix mutated into
the current God-knows-what thing.)

Thomas

On Mon, 2010-01-11 at 21:46 -0800, Derick Eddington wrote:
> 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...)
>