A curious parallel between program expressions and file paths
Posted: Wed Mar 19, 2025 9:28 am
I was just re-reading The Hideous Name by Rob Pike and P.J. Weinberger. I've been undecided about the uniform paths recommended by the paper, but I was surprised when the paper made a parallel between the "bad example" of VAX/VMS and C syntax expressions. I was especially surprised because I have independently found I prefer the uniform expression syntax of Forth, corresponding more closely to the uniform paths of Unix.
A bad example: VAX/VMS
Unfortunately, not everyone chooses naming conventions in accord with these guidelines. On VAX/VMS our canonical file might be called UCBVAX::SYS$DISK:[ROB.BIN]CAT_V.EXE;13. The VMS file naming scheme provides a distinct syntax for each level in the name: UCBVAX:: is a machine; SYS$DISK: is a disk (actually a macro that expands to a disk name such as DUA0:); [ROB.BIN] is a directory; CAT_V is a file ‘base’ name; .EXE is a file ‘type’; and ;13 is a version number.
Although this syntax may seem unnecessarily cumbersome, it has a precedent: it is analogous to expressions in programming languages. Consider a C expression such as *structure[index].field->ptr. If * were postfix and / the only dereferencing operator, the expression might be written structure/index/field/ptr/. Functionally-minded programmers might use the notation contents(ptr(field(index(structure)))). (A single character cannot be used in C because it could not distinguish X[Y] and X->Y, with X a structure pointer and Y an integer or structure element respectively, but this ambiguity could be eliminated in a different language.) C and VMS use syntax to distinguish the types of the components of a name. Instead, the UNIX file system deliberately hides the distinctions. Aside from the obvious advantages such as simplicity of syntax and the usurping of only a single character, the uniformity also makes the name space easier to manipulate: the mount system call aliases a disk and a directory.
Forth has its operator-like variations. Colon and semicolon, starting and ending definitions, could be anything but they're single punctuation characters to stand out, as are many other 'words'. Over 10 years ago, thinking about coding on my phone with its relatively small screen and limited on-screen keyboard, I realised that even the arithmetic operators don't need to be symbols. That would have been a funny-looking language if I'd implemented it: "IF col mul add to col ELSE row 10 mul add to row ENDIF". This really blurs the fact that "to col" is an assignment. It's clearer when you see, "col * + to col" etc. All in all, I like that Forth uses symbols, but I also like the freedom to define things with or without symbols as needed, and to change the syntax in deeper ways on a temporary basis. Local variables in some Forths are almost a separate tiny language, but it's a very convenient one.