Hi Duncan,

It is often useful to have paths in the reverse order. And it is
especially useful for sharing prefix without duplication.

However, I don't know how it can enter in your design.

Le Fri, 25 Sep 2026 12:40:56 +0000,
D Guthrie <xxxxxx@posteo.net> a écrit :

> 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