Email list hosting service & mailing list manager

Re: SRFI 170: 270 days John Cowan (06 Feb 2020 03:52 UTC)
Re: SRFI 170: 270 days Arthur A. Gleckler (06 Feb 2020 05:51 UTC)
CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:34 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 15:42 UTC)
Re: CWD and other unresolved issues Lassi Kortela (07 Feb 2020 15:47 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 18:04 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 18:48 UTC)
Re: CWD and other unresolved issues Per Bothner (07 Feb 2020 18:57 UTC)
(missing)
Re: CWD and other unresolved issues Per Bothner (08 Feb 2020 07:33 UTC)
Pathnames and URIs Lassi Kortela (08 Feb 2020 09:12 UTC)
Re: Pathnames and URIs Lassi Kortela (08 Feb 2020 09:20 UTC)
Re: CWD and other unresolved issues John Cowan (08 Feb 2020 18:58 UTC)
Pathname representations Lassi Kortela (07 Feb 2020 22:19 UTC)
Re: Pathname representations Per Bothner (07 Feb 2020 22:32 UTC)
Re: Pathname representations Arthur A. Gleckler (07 Feb 2020 22:36 UTC)
Re: Pathname representations Lassi Kortela (07 Feb 2020 22:50 UTC)
Re: Pathname representations John Cowan (08 Feb 2020 07:02 UTC)
Re: CWD and other unresolved issues John Cowan (07 Feb 2020 19:01 UTC)
Re: CWD and other unresolved issues Arthur A. Gleckler (07 Feb 2020 19:20 UTC)
Re: CWD and other unresolved issues Marc Feeley (07 Feb 2020 20:15 UTC)

Re: Pathname representations Per Bothner 07 Feb 2020 22:31 UTC

On 2/7/20 2:19 PM, Lassi Kortela wrote:
> 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?

Yes.  If you want to have the small-possible veneer over the Posix APIs I guess you could have
per-process CWD.  But per-thread CWD seems much more useful: If one thread changes CWD,
I don't think you want that to be visible in other (already-running) threads.

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

In Kawa, the relevant functions can take a path object *or* a string, so it should be quite convenient.

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

As they can in Kawa.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/