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

Per:
> Please also look at the Kawa path API:
> https://www.gnu.org/software/kawa/Paths.html
> I put quite a bit of thought into it, specifically
> to integrate filenames, URIs, and URLs into a coherent framework.

Interesting. According to that page, Kawa also has a per-thread working
directory. Per, do you feel strongly like Marc that a per-thread rather
than per-process CWD is the right way to go?

Re: pathname representation, it seems clear that we have two camps:

* Record-like abstract data type (MIT Scheme/Kawa/Racket/Common Lisp)
* Strings (most other Schemes and Python, Go, etc.)

Personally, I have to side with John. I have extensive experience with
both styles and have to say that I find the strings-only style far
superior. I've used the pathname ADT in Common Lisp, and the pathname
and URL ones in Racket. In principle, the ADT sounds much better but in
practice it has consistently led to verbose and hard-to-understand code
for me. I haven't used the Kawa or MIT Scheme pathname APIs; they may be
substantially different in practice.

A large part of the problem is that Unix style pathnames are basically
directory-only, so the 6 or so components in Common Lisp pathnames
basically sit empty all the time. The difference between directory and
filename is often ambiguous, and with wildcards it's especially so.
Pathnames are often imported and exported from syscalls and other
programs which use strings.

In Racket, I've found the URL functions really hard to understand.

By contrast, I can only say good things about the minimalist Python and
Go pathname APIs. They present a lightweight level of abstraction that
consistently does just what I want.

If we have a clear lightweight API camp and a clear heavyweight API
camp, I don't want to push my minimalist views on others but would
rather honor both and think about interoperability between them. Scheme
is not well served by further divisions. At the end of the day, the
pathname/URL ADT always has to resolve to a string representation, so if
functions that take pathnames can take either a string or a pathname
object, things should be mostly OK. I've consciously taken care to write
all my pre-SRFIs dealing with pathnames so that they can take either one.