Hi Wolfgang, I'll reply inline…
> On 15 Sep 2026, at 02:16, Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
> Hi Duncan,
>
> Thanks for working so hard on this SRFI. It is more than I can keep in
> my head, unfortunately, but it has clearly been written with care. I
> have a few minor issues:
>
> 1. Pedantry: The R7RS example in the “R6RS Conditions” section uses
> square brackets, which are “reserved for possible future extensions”
> by R7-small. Of course it’s clear what they mean, but, strictly
> speaking, they make the example invalid R7RS-small code.
I didn't realise - the next draft can modify the examples to use regular
brackets.
> 2. Awkward argument names: Why isn’t the common ‘nonempty-ini?’
> argument called ‘nonempty-initial?’ or ‘nonempty-init?’ instead?
> (Is this a tribute to the ‘creat’ of UNIX infamy?)
>
> 3. I don’t understand why there are two-argument versions of
> ‘update-iri-authority’ and ‘update-uri-authority’. If I understand
> correctly, ‘(update-iri-authority IRI #f)’ is the only valid use of the
> this form, and it’s equivalent to ‘(update-iri-authority IRI #f #f #f)’.
> It seems to me the #f argument isn’t doing anything. You could get rid
> of the two-argument version, or replace it with a one-argument version,
> ‘(update-iri-authority IRI)’.
>
> In passing, I note that only the two-argument version of
> ‘update-uri-authority’ is mentioned in the “URI programming interface”
> list.
It's for parity with iri-authority. To be specific, this procedure exists
because it's quite widespread in existing libraries, which tend to treat
authority as a single component (in Chicken it's a record) consisting of
the three. The single-value case of both getter and setter can just be
ditched.
> 4. The types of some arguments are specified neither in the procedure
> spec. nor in the “Argument restrictions and convention” (that section
> name needs a final ‘s’, too):
>
> * update-iri-authority: *user*, *host*, & *port* are of unspecified
> type, except we know they may be false.
>
> * resolve-iri, etc.: *base* (clarified by the ‘relativize-iri’ spec.,
> possibly: that procedure’s *base* argument must be non-relative,
> which I suppose applies to all *base* arguments.)
>
> * encode-string, etc.: *char-set*. Of course character sets are
> discussed later, but it wouldn’t hurt to clarify the type of this
> argument. (Most likely it should be added to the “restrictions &
> conventions”. It’s used often enough.)
>
> 5. What does ‘path-ref’ do when the index argument is invalid? The
> example (non-normative, I suppose) says “ERROR”.
I'll clarify (4) and (5).
> 6. General: (srfi :275 path) seems very large; in particular, there are
> a lot of constructors. I’m probably missing something, but are all the
> ‘vector->’ constructors needed in addition to the more general
> ‘build-path’? (The usefulness of the ‘string->’ constructors I
> appreciate.) And are all those predicates needed, too?
The main argument for providing the predicates is so that library users
can implement their own normalization procedures. There is a need in
these cases to check that a path which was produced is consistent with
the RFCs.
I don't think we want to get rid of these as it's very tricky to n
ormalize IRIs and URIs and preserve internal consistency.
The vector constructors exist because the path segment procedures return
a vector. One option might be just to modify `path-segments` and similar
to return lists of segments, then `build-path` is the constructor,
although then we'd presumably come up with list conversion procedures.
I'm not really sure about this one.
I agree that the `rfc-` prefixed constructors can largely be eliminated,
as they're not useful in the same way as the predicates are in
normalization.
> * * *
>
> Thanks again for all your work. I’m probably missing a lot of
> important details, but hopefully the other, more *RI-knowledgeable
> commentators have gotten to them.
Well, thank you for your review. This is the first proposal I've written
up, so I really appreciate the comments.
Best,
Duncan
