Dan Rose

@triska, the `files` library seems like it should either be operating-system independent and operate purely on platform-independent paths (requiring `/` and maybe even throwing an error if `\` is found)...

Both slash and backslash are explicitly supported in Windows paths. They are synonymous as directory separators, but of course, paths on Windows can be a bit tricky.[^0] > `library(files)` uses...

> > not sure if you're talking about normalizing to the host platform > > That's what I meant. Normalize to use what Rust calls the **main** separator, on the...

Yes, I sometimes use Windows, but I prefer MacOS and use it more often. Paths don't need to be *completely* opaque terms; most of the time, they can indeed be...

> > [...] most of the time, they can indeed be spelled as strings. > > This ignores the important point I brought up that paths are in general not...

> Therefore this only actually works if the internal representation of the joining of two paths is literally `/(A,B)`. Yes, the representation *is* redundant. So for instance `(A / B)...

> > have a path be either a list of chars or a term with principle functor `(/)/2` > > I understand the temptation of defaulty structures, along the lines...

> > The question "what is the next segment in the path" is extra-logical - it CANNOT be written in an environment-agnostic way until the path is processed in an...

> Currently, `path_segments/2` uses a **list** where each element is a path segment. To me, a list seems an ideal representation to represent a sequence of segments. A list can...

> ~~It seems `predicate_property/2` would be a good candidate for inclusion in the standard?~~ ~~What do you mean?~~ It *is* in ISO/IEC 13211-2: > ## 6.8 Predicate properties > The...