[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

a problem with terminology

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