Do not get me wrong, but is there really a need to make this an SRFI?
The format is simple, the implementation is straightforward, and portable.
Isn't the biggest advantage of the library system being able to reduce
the need for social interaction for such cases?

I mean, INI files are generally very varied, and frankly ill-defined.
Sometimes repeated sections are expected to override each other,
sometimes they are expected to be read as a list, and sometimes they
are forbidden. This is just a single example.

The goal of "agreeing upon the best fitting INI format for the Scheme
world" would make sense, if Schemers wouldn't be way more likely to
prefer s-exp based configuration formats. (And there are libraries
such as (chibi config), which semi-automate serialising configuration
into files.)

Another noble goal might have been to "do an extensive research and to
create an exhaustive model for INI files for everyone's reference".
But this srfi does not seem to have such a goal?

For comparison, python's configparser has the following parameters, in
addition to a complex system of errors matching it:
```
class configparser.ConfigParser(defaults=None, dict_type=dict,
allow_no_value=False, delimiters=('=', ':'), comment_prefixes=('#',
';'), inline_comment_prefixes=None, strict=True,
empty_lines_in_values=True, default_section=configparser.DEFAULTSECT,
interpolation=BasicInterpolation(), converters={})
```
and still, it does not cover all possible INI files.

Sorry, I may be wrong, but community processes (such as SRFI) are
sometimes seen as a sign of "endorsement" for something by the said
community,
 and I just don't see the case for endorsing INI files by Scheme
(broadly understood).

As a legacy-supporting interface, obviously, such a library is very
useful, but wouldn't a snow2 package be more appropriate in such a
case?

On Thu, 11 Aug 2022 at 12:36, Vladimir Nikishkin <xxxxxx@gmail.com> wrote:
>
> Do not get me wrong, but is there really a need to make this an SRFI?
> The format is simple, the implementation is straightforward
>
> I mean, INI files are generally very varied, and frankly ill-defined.
> Sometimes repeated sections are expected to override each other,
> sometimes they are expected to be read as a list, and sometimes they
> are forbidden. This is just a single example.
>
>
> On Thu, 11 Aug 2022 at 03:21, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
> >
> > Scheme Request for Implementation 233,
> > "INI files,"
> > by John Cowan (text), Arvydas Silanskas (code),
> > is now available for discussion.
> >
> > Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-233/.
> >
> > You can join the discussion of the draft by filling out the subscription form on that page.
> >
> > You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.
> >
> > Here's the abstract:
> >
> > An INI file is a configuration file that consists of key-value pairs for properties, and sections that group the properties. The name of these configuration files comes from the filename extension INI, short for initialization. The format has become an informal standard in many contexts of configuration. This SRFI provides access to the contents of an INI file.
> >
> > Regards,
> >
> >
> > SRFI Editor
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin
> (Sent from GMail web interface.)

--
Yours sincerely, Vladimir Nikishkin
(Sent from GMail web interface.)