Hi folks,

Further to the discussion about the path sub-library…

There is a procedure, `path-segments`, which retrieves the internal representation of the path as a *vector* of string segments. (Nothing is said about what that internal representation is, but in the sample implementation, it's a vector of segments which may be percent-encoded.)

There are then corresponding constructors, `vector->absolute-path` and `vector->relative-path`.

However, there is an additional procedure, `build-path`, which is variadic. Wolfgang in his email queried about whether the vector constructors are necessary. I am writing as I am really not sure how to respond, and I'd appreciate some feedback before firing off another draft. There's a couple of strategies I've been thinking about:

a) Remove the `vector->` procedures altogether. This would leave `build-path` (or the string conversion procedures) to construct paths, but then unmodified `path-segments` retrieves a vector of segments.

b) Modify `path-segments` to return a *list*, and replace the vector procedures with `list->` procedures.

c) Modify `path-segments` to return a list, but don't offer `list->` procedures in addition to `build-path`.

I'd like to understand what sort of conventions there are in the community. Vectors seemed sensible to me to return in a high-level interface, because paths are naturally represented as sequences, and general purpose applications of these (like library modules) can get large quickly. But the generalised sequence libraries like mappings offer procedures which work on alists, and of course `build-path` is implicitly working on a list (of args) representatin. I'm simly not sure how to align the behaviour nicely.

--

For the next draft, I also had a more general think about how to cut down the number of path constructors, based on the discussion so far, and I'm very likely going to do the following. (You can see my changes here - https://codeberg.org/dguthrie/scheme-iri/src/branch/srfi-275bis/doc/srfi-275.html).

a) Remove the `vector->rfc-` procedures  and `string->rfc-` path encoders. These were just wrapping default args and the document is quite long already.

b) Eliminate `iri-path-string`, `uri-path-string`. These are always simple composition of `path->string` and `iri-path` (there is no #f case for paths, we have the empty path). Similarly eliminate `iri-path-segments`, `iri-path-absolute?` &c.

c) Remove the dubious single-value cases of `iri-authority`, `update-iri-authority`.

d) Rename the remaining `rfc-` procedures to refer to the specific RFC. The names are slightly longer but feel less unexpected (and we can reasonably anticipate updated RFCs within the coming years). The path predicates are named `rfc3987-` because the character set corresponds to characters permissible within IRIs.

--

Thanks again,
Duncan