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