I agree very much with everything Daphne wrote here. Am So., 20. Feb. 2022 um 09:25 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>: [...] > >> 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"? > > Pretty much, yes. Especially the latter. I consider it moderately catastrophic that we claim to be developing a practical language for mainstream software development, have got to the stage we’re at, and still don’t even have a condition system on the agenda. > > > 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. > > I would rather say to implementers: if you want the small language, you know where to find it. Full support only for the small language is a legitimate choice. You can’t make an omelette without breaking eggs; I’m increasingly convinced that the goal of trying to make a ‘practical language for mainstream software development’ while keeping the same laissez-faire attitude to error conditions, and making the same numerous compromises, as R7RS small is just not going to work. In fact, if R7RS-large wants to fulfill the goals that are set for it, it will have to include a subset equivalent of R6RS anyway. Now with syntax-case having become a part of R7RS-large, everything speaks for actually using R6RS as this subset and not to create something incompatible. > Anyone who is seriously maintaining an implementation which isn’t willing to make major changes for the sake of Large support was alienated, at the latest, on Tuesday this week by the adoption of syntax-case. (I don’t see Chicken or MIT adopting more of Large now, for example.) > > I prefer a long-term, carrot-based approach to getting implementers on board: at some point, I hope the number of R7RS Large-compatible portable libraries — especially ones which really, with good reason, *need* the Large language and its guarantees — will be sufficient to encourage holdouts to adopt the Large language. > > That’s not to say I’m not concerned about implementations. It’s a problem that we don’t have an implementation which is committed to keep up to date with implementing the whole thing; nothing, in other words, that takes the rôle Chibi had during the small language’s development process. (Alex said in the release notes to 0.9 that Tangerine would likely be the last edition to be fully supported by Chibi.) I’d be willing to start one if enough fundamental questions about language design and cleanup were already answered, but those questions aren’t on the horizon. A standard without implementation is a dead standard; I think everyone agrees on it. For R7RS-large, the bar is set even higher; we won't need just any implementation, we will need an implementation that is as mature as, say, GCC or Clang in the C world. Thus, we will probably have to build on existing implementations; no one can recreate what went into Gambit, Chez, Racket, etc. for twenty or thirty years or more in a year or two. At least as much as with implementations, we should be concerned with the audience of the standard. It's a difference if we want to address some niche programming projections or if we want to see wider adoption of the resulting language in mainstream software development. In any case, R7RS-large has to offer more than existing standards and (!) tools. At the moment, for example, using R6RS together with some existing portable libraries (e.g. SRFIs) still gives me a more productive environment than the current R7RS-large. When I look at what is to be voted into soon, this won't change for a long time. > > 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. If you have a pure way to do something and a not so pure way (but which may have worked in practice so far), if the pure way does not come with any serious disadvantages, there is no reason not to choose the pure solution. > André Sá pointed one out: ‘If I have a list of ports `l` and want to read the contents of all of them, `(map (cute read-string #f <>) l)` is one "obvious" way to go.’ <https://srfi-email.schemers.org/srfi-discuss/msg/18005658/> > > One thing I would point out is that there’s nothing wrong with in-band signalling of the end of stream; the problem is that the EOF object both (a) is accessible to all Scheme code and (b) has other meanings and may legitimately arise in other situations like the one pointed out above. > > > (Note also that eof-objects are not magic in > > SRFI 41, so you *can* generate and consume such streams if you want them.) > > But without the performance benefits which are supposedly the purpose of generators. > > >> 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.. > > Which would be another abuse of PFNs to make changes to the Large language by fiat of the SRFI authors, imo. > > My compromise proposal is this: we define a new iteration protocol without the eof-object problem, with multiple values, and possibly with the option to traverse the sequence in pure-functional style. We keep generators but attach a warning to them that they are only designed for IO-based/parsing use cases, where the ultimate source of data is an input port. I would still rather see them gone entirely, but in cases where EOF really can only mean EOF, I guess they aren’t harmful. I can subscribe to all of this. Maybe just one comment: As long as we don't officially sanction lexical syntax for the eof object, using generators to read and write Scheme datums (with lexical syntax) is fine.
