On Tue, Oct 26, 2021 at 3:27 AM Marc Nieper-Wißkirchen <
xxxxxx@gmail.com> wrote:
Can you explain what the purpose of this two-stage process is? If, at every e step, the same majority is needed, I see no harm in adding proposals for incompatible changes directly to the ballot (as long as it is made clear that such a change overrides some earlier decisions).
Parliamentary procedure does not presume that the majorities are the same. Suppose that two proposals named C (compatible) and I (incompatible) have been made for a given ballot question, and the voters are Alice, Bob, Carol, Dave, and Erin. John, the chair, rules proposal I to be out of order, and Erin appeals. Alice and Bob vote to sustain the Chair, and Carol, Dave and Erin to override, so the Chair's decision is overridden.
However, Alice, Bob, and Carol in fact prefer C and vote for it, and Dave and Erin prefer I, so C passes. This arises because Carol thinks that Erin and her friends should be allowed to have I appear on the ballot even though she opposes it.
So why does John not agree with Carol and just allow both I and C on the ballot in the first place? Two reasons. John believes that people using a previous edition of R7RS in good faith are entitled not to have a future edition break things out from under them. John also believes (from experience) that too many proposals on the same ballot question makes it unlikely that any proposal will get a majority of the legal votes cast, thus carrying the question to another ballot, possibly indefinitely.
> I am not sure whether it was even discussed or whether the voters were aware that the claim in SRFI 158 that generators can be used as "glue" between sequence types is not correct.
No decision system, democratic, aristocratic, or monarchic, can possibly depend for its validity on whether the decider(s) are aware of this or that in a particular case. The most that can be demanded is that the information in question was not kept secret from them, which it wasn't. It's up to the decider(s) to figure out the consequences themselves -- if they can.
The problem are statements like "The combination of make-for-each-generator and
generator-unfold makes it possible to convert any
collection that has a for-each procedure into any collection that has
an unfold constructor. This generalizes such conversion procedures as
list->vector and string->list."
I should have written "collections of any type", which better expresses my meaning, and that should be part of the same erratum (but see below). A reference to the previous erratum text would not be out of place, though not strictly necessary.
These must be dropped from SRFI 158. For the same reason, generators are generally not a replacement for SRFI 41 streams (which do not have the eof issue).
SRFI 127 has the same problems as SRFI 158 when it comes to generalizing to situations where the eof object is not special. It should also be reviewed.
That suggests better wording for the erratum: "It is an error to construct or use a generator that returns an eof-object before it is intended to be exhausted, for example by ..." I also need an erratum or PFN to make 127 refer to 158 instead of 121. 158 generators are compatible with 121 generators, so that should do it.