On Oct 29, 2008, at 12:45 AM, Elf wrote: > On Tue, 28 Oct 2008, Mitchell Wand wrote: > >>> From: Elf <[EMAIL PROTECTED]> >>> To: [EMAIL PROTECTED] >>> Date: Tue, 28 Oct 2008 03:29:07 -0700 (PDT) >>> Subject: [r6rs-discuss] voting process prequel >>> >>> notable issue with the announcement and voting process: what, >>> precisely, >>> is the role of the steering committee, and how does it differ >>> from the >>> role of the editors? i cannot seem to find a document explaining >>> the current (and future) roles of both parties. >>> >>> -elf >> >> The roles of the steering committee and the editors committee are >> explained in detail in the Charter. This *used* to be available on >> schemers.org, but it seems to be hiding from me right now. >> It's not that long, but it's too long to post here, so I've put a >> copy >> online at http://www.ccs.neu.edu/home/wand/charter.txt . >> >> I'll try to get this fixed up, so there are links on www.r6rs.org, in >> the voting procedure document, etc. >> > > Oke, thank you for posting this. I now think I have a clearer idea > of the > roles. Some questions, then: > > 1) Which Steering Committee member(s) are leaving? > > 2) When was the Steering Committee and Editors process > established? Can > someone post a brief history of the processes by which the > historical > RnRS reports were standardised, and how the current process was > decided?
Sussman and Steele wrote Scheme definitions in 1975 and 1978. Groups at MIT, Indiana, Yale, and elsewhere started writing implementations that began to diverge in ways that were seen as perhaps not necessary. A meeting in the early 1980s achieved the first act of reconvergence, which was agreement among three implementations on the name 'call-with-current-continuation'. The first 'scheme authors' workshop, including a larger group of (mostly) implementors, convened in fall of 1984, and I think that's where the unanimity rule started. This group met several times - in person, since unanimity doesn't work so well by email (and email didn't really work very well in 1984) - creating four reports. A largely overlapping group created the ISO Scheme standard under ISO rules. The unanimity rule led to stalemate on all important issues, and a different process not requiring unanimity (the steering committee / editorial committee plan) was proposed. The new process was discussed at a Scheme workshop, and met with general assent among those present (it was never taken up with the "scheme report authors" AFAIK). This new process - unrelated to the previous one except for having some common members - created R6RS, confusingly using the same report naming scheme as the other group's R(n)RS series. Dropping the unanimity rule and establishing an editorial committee created a spec having a substantially different character from previous ones. > 2a) If there were a significantly different set of processes for > the previous > RnRS (n <= 5) standardisation efforts, what was the rationale > for changing > to the current one? Meeting needs of people who for whatever reason wanted agreement among implementations on records, modules, exceptions, unicode, etc. Their needs were not being met by the previous process. > 2b) If the process for R6 strongly differed from the previous > processes, I > would suggest fairly drastic modifications to the Charter and > standardisation process itself. For example? > 3) I am concerned about excessive democracy in standardisation > processes > without some form of check to prevent fiascos like Common Lisp > (sorry) > or the political and social effects of R6RS. What checks can > be put into > place to prevent future scenarios like the one currently > encountered, if > a popular vote is to be the method of selection? (I assume you mean the ratification vote.) Democracy is a difficult thing to relinquish voluntarily, although this has been done. I observe that one generally gets a quality specification by having a small, compatible, undemocratic group work privately, closely, and intensely for a time, and then going public, letting communities attract to the spec's merits. This is how Scheme became popular in 1978, and the same model holds for Perl, Python, Ruby, and so on. As the community builds, it wants influence over revisions, and when they get this influence, the revisions sometimes lose the character of the original. HTML5 is a current example of this transition - its working group and spec bear almost no resemblance to those of HTML4. When the stakes go up, the interested parties don't necessarily like one another so well as when contributors were united by taste, and that un-fun-ness shows up in the new specs. Not sure what you mean by Common Lisp being a "fiasco" - as the high- stakes followon to an earlier Lisp, with the explicit goal of being comprehensive, it actually did relatively well and managed to stay coherent in spite of market and user pressures that Scheme never saw. The ANSII version took a long time, but I suspect there was a reason, such as lack of resources. > 3a) How soon will a Steering Committee actually have a new set of > tasks? R6RS > is less than half a year old. the date on http://www.r6rs.org/final/r6rs.pdf is 26 September 2007. ratification was 13 August 2007. > > 3b) What is the unifying concept of Scheme going to be? What is > the desired > direction? How can the dichotomy between the purists and the > applications > people be resolved? I think that these are the fundamental > questions that > must be addressed before any further decisions or discussions are > warranted. This is the question of the day - although I don't think I could put many of the R2RS authors in either category. For me the split has to do with the bar on what goes into "the language" or "the spec". In 1980, Scheme was about learning things, having fun, and language kernel simplicity. The new effort (R6RS...) seems to be about comprehensive specs that help you write practical programs that port between conforming implementations. The dichotomy is not between pure and applied, as you can write (nonportable) applications satisfying an incomplete spec, but between those looking for a language-defining document reaching a very high bar (and therefore failing to solve many important problems that lack good solutions), and those who want a complete but compromise-prone spec that maybe not all of their friends totally accept. I think it is natural that if you don't know how to do something in a way that's to everyone's taste, but you still need to do it, then you do it somehow. With the original veto-intensive report series this useful, not-ready-for-prime-time work was done in the privacy of one's own implementation, and we were supposed to coordinate with other implementations bottom-up through SRFIs, which brilliantly were not identified with Scheme. But now that there's insistence on a spec supporting portability, the not-ready is done center stage, in the spec. I'm afraid I have a cynical view - there really is no resolution. We don't know how to design a rich language for "applications" that everyone will accept. When the lets-have-fun people lose their thats-not-fun veto power, you get a useful language in a timely manner that many like and some dislike. Maybe eventually a deep, tasteful, widely acceptable solution will be found to every design problem, but not everyone can wait that long. I guess there's no reason in principle that both needs (perhaps they even overlap) couldn't be satisfied, but you would need two reports produced by two different processes. Process changes, such as a transition to a conventional consensus- based working group structure (which is NOT what was followed either pre or post R5RS), should be considered as ways to get some of the benefits of unanimity without risking stalemate. Look around at working groups that work well and figure out what to emulate. Structural changes such as separate working groups for kernel and library, or (near-)unanimous features vs. majority features, might help too. Jonathan _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
