Am Fr., 30. Sept. 2022 um 22:35 Uhr schrieb John Cowan <[email protected]>:
[...] > 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). > Okay. In any case, adding a warning as a note to SRFI 233 may help to make this problem better known. > 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. > You are right, of course. This is also the behavior of `read` and `write` in Scheme.
