Last call for comments on SRFI 261: Portable SRFI Library Reference Arthur A. Gleckler (07 Oct 2025 00:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 05:41 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (07 Oct 2025 05:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 06:10 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (07 Oct 2025 11:56 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 12:07 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 07:37 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (08 Oct 2025 08:46 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 14:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (08 Oct 2025 15:25 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 21:26 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 14:39 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Peter McGoron (09 Oct 2025 16:04 UTC)

Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Peter McGoron 09 Oct 2025 16:03 UTC

I just want to state my case for my favorite part of the SRFI one last time.

I still support the name-### references and think they are better than
the SRFI-97 naming system. Such a naming scheme could also be extended
to features identifiers and reader directives in future SRFIs, with the
groundwork for such things laid by this SRFI. They are also compatible
with the R7RS way of referencing SRFIs: `(srfi mappings-146 hash)` and
`(srfi 146 hash)`, versus the R6RS/SRFI-97 way of `(srfi :146 mappings
hash)`.

Now that that's out of the way, some points if you do make the changes
you state, irrespective of your action on name-### references:

If you add R7RS-style references, note that common usage of R7RS
references is not equivalent to SRFI-97 style references for
sublibraries. For instance, the "hash" sublibrary in SRFI-146 would be
referenced as "(srfi :146 mappings hash)" in the SRFI-97 style system,
and "(srfi 146 hash)" in the R7RS-style (this is what is said in
SRFI-146 itself). The SRFI could either mandate it to be like SRFI-97,
or it could mandate the R7RS way for `(srfi ### ...)`.

I agree on removing the library names list, it has proven too difficult
to get right. There still needs to be some wording about library names
though, because at minimum SRFI-97 colon-references need names for
sublibraries. I would recommend the SRFI state that the library name
used in library references is either the name specified in the SRFI, or
in the library-name metadata of the SRFI, and leave it at that.

-- Peter McGoron