This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
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...) >