Looks like Common Lisp's pathnames. In practice, though, they are *too* general, and you need an implementation-dependent parser and unparser which understands only the native format. Python, and my variant of it, deal only with Posix and Windows, which is all that are needed in practice nowadays, and provides portable parser/unparser pairs for each.

I never used TOPS-20, but I did use versioned files on VMS. I normally set the versioning limit to keep only the current and the one before that. IMO, version control systems and journaling file systems eliminate the need for versioning in the file system.

On Fri, Feb 7, 2020 at 1:48 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

On Fri, Feb 7, 2020 at 10:04 AM John Cowan <xxxxxx@ccil.org> wrote:

The RnRS standards don't specify how the arguments to open-*-file are mapped to the kernel's interpretation of native paths, so something like this is up to the implementation. However, the <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PathnamesPython.md> pre-SRFI specifies a fully portable method of manipulating Posix and/or Windows pathnames. It was easy enough to add a current-basepath parameter to use when joining paths. I suppose a convenience path-join* procedure that uses (current-basepath) could be added, but (path-join (current-basepath) path) is easy enough. Note that unlike in Python itself, the path objects are lists of strings rather than opaque records.

Speaking of pathname-manipulating APIs, have you seen MIT Scheme's pathname API? It's well developed, and supports all kinds of filesystems going all the way back to the civilized days of versioned files in TOPS-20.