On Fri, Sep 30, 2022 at 11:16 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
> Okay, but then I don't understand the reference to "ill-formed" in the > last sentence of the rationale (in your private draft) anymore. > Rationales are not, of course, normative. But I changed it to "unconventionally formatted". And if there is no ill-formed INI file, I even more tend to agree to > those who think that standardizing anything about them is not a good > idea. > I am not attempting to standardize INI files, only a mechanism for reading and writing them that handles common cases without losing information about uncommon ones. As I > said, not using symbols in SRFI 233 is only a solution as long as the > programmer doesn't use string->symbol, etc. > Daphne convinced me that this concern is pointless, because SXML and various JSON libraries are already interning untrusted input right and left. So section names and keys (but not values) will be symbols. In addition, lines without brackets or = will be values with key #f instead of keys with value "" (but this change has not yet been made). Arvydas, can you make the above fix to johnwcowan/srfi-233? I don't quite follow the logic of the parser. I don't understand why this should be an oddball use case. And why > "jumping through hoops"? tt would be enough to say something with the > effect that the generator and the accumulator are not lazy. > Well, no. To impose this restriction, the SRFI would have to say that the generator must be lazy in the sense that it must not consume from its port more than necessary, and the accumulator must be eager in the sense that it must push to its port all that it has available when it is called.
