On Thu, Feb 17, 2022 at 8:18 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
On 9 Dec 2021, at 23:43, John Cowan wrote:

> Of course you know what I'm going to say next.  There is simply nothing
> wrong with an inbound signal indicating the end of a generator stream,

"In-band", that is.
With strings, Large should either make its mind up, or force implementers to make their minds up, between two options: NULs in strings are allowed; or they are not allowed.but a catchable, distinguishable error is signalled if you try to make one. 

Fair enough, and I'd be happy to add a SRFI that provides this guarantee.
Silent failure, mysterious truncation, and nasal demons are unacceptable in ‘mainstream software development’, where untrusted input from malicious sources is a daily reality.

But where do we stop?  Do we insist that all "is an error" conditions (of which only a fraction are actually marked with that phrase) and all "an error is signaled" conditions be converted into "an error is signaled satisfying"?  We can certainly do that, but then we re-create the R6RS situation, namely that no existing implementations can conform to R7RS-large, which stirred up huge amounts of disputation when R6RS came out?  I would consider that a failed outcome.  Or as Dennis Ritchie supposedly said when people complained about the lack of features in C: "If you want PL/I, you know where to find it."  The same is true of R6RS.

With generators, I could possibly accept that an error is signalled if you try to create a generator from a sequence that contains an eof-object, but given that generators are lazy (unlike strings), this seems hard (though not impossible) to guarantee in the general case in a way that safely distinguishes such erroneous eofs from the actual end of the stream. And of course, this does not solve the problem that generators cannot be created from any arbitrary sequence (it merely makes it more visible),

Scheme is not a pure mathematical abstraction: it is a tool for programmers, and tools have uses.  What is the *use* of such a sequence?  Nobody has answered that.  (Note also that eof-objects are not magic in SRFI 41, so you *can* generate and consume such streams if you want them.)

nor that generators can only return one value per iteration, etc. etc.

That would be easy to remove by erratum or PFN (change "return a value" to "return one or more values") but it would not mean that the SRFI's procedures should, much less must, be accommodated to such multiple-value situations..