The poll closed at 10:00:00 GMT on Monday, August 13 (the end of the day on August 12th in Honolulu - the location of our westernmost voters). After the poll closed, people continued to send us additional ballots and requests to modify their ballots. Since we had been quite clear about when the poll would close, this additional correspondence could not be counted in the official results.
Because these messages were clearly sent in the honest (but mistaken) belief that they were not too late, the Steering Committee agreed to publish this additional correspondence as an appendix to the permanent record.
In favor of ratification:
Opposed to ratification:
Wishing to change to opposing ratification:
Scheme is a small core language with some evoluated features built on the cores. This way, it s easy to port it on small embedded devices. I really do not like the way you manage modules/librairies/external. You seems to make the Java mistakes and try to have a language with so many librairies instead of a language AND some librairies you can plug in. I prefer the concept of SRFI. The language and the libraries must be distinct... but, it must have a standard way to plug libraries.
Thank you for all your hard work.
Although I am happy that appropriate changes have been made to better acknowledge the work of the authors of the previous document, I continue to believe that there has been a strong change in the nature of the document that makes it not suitable for continued rev'ing of the old name. I would prefer to see a new name. My negative vote at this time should in no way be taken to deny the important work being done now, however I strongly believe that this latest work is the beginning of a new series, not the end of an old one. I think a new series of documents, beginning with a version zero (which may be the drafts leading up to this) and a version one (which might be the ratified version) is the right way to tell that story. I think the old effort had different goals and that it's better to leave it historically stable and consistent with existing publications than to force the community into a sense of upheaval. There may well be a sense that beginning a new document could fragment the community. If that happens, so be it. I don't think it will. The fact is that the new changes should attract the lion's share of the audience, so I don't really see that happening. But if to my surprise there are people that don't accept the new document, they should be entitled to continue to have the old document available under a name they can easily refer to. I think the breaking out of the document into multiple documents is also appropriate and again will confuse the naming if one wants to compare this set of documents to the old single document. Again this is a reason to separate the series-identification. I would change my vote to Yes if this document were renamed to have a new identity that did not conflict with the old report.
The R5.97RS draft represents a significant and valuable contribution to the Scheme language and I look forward to the eventual ratification of a draft in this series, however I feel the current report has a few fundamental issues that must be addressed before finalization. There are also numerous smaller issues, both technical and editorial, that I would like to see resolved. My hope is that, should the ratification of 5.97 fail, the editors will consider and respond to the issues raised by the electorate in their ballot comments and produce a revised draft, then conduct another one or two public review rounds with formal comments and responses, perhaps on a shorter schedule than with the previous rounds. With each round, the editors should produce another draft revision. I'm confident the current draft would be vastly improved by such an effort and would feel comfortable ratifying the document.
I feel that the scheme standard is making a wrong decision in presenting with the current draft because the SRFI process is largely ignored by the draft. Also the removal of load is a problem because of the fact that I believe it should still exist in the standard because of its importance to scheme especially using a REPL. Another problem I have with the standard. Another problem is the record library which is horribly broken and must be replaced before I can approve of the draft.
The language as proposed by 5.97 has gotten too complicated both for students and for implementors. Too little attention has been paid to backward compatibility. There is a large body of existing Scheme code that no one has time to rewrite to meet the new standard. In the past, new language features were implemented, and only then proposed as standards. The latest draft standard is proposing too many features for which the community has little or no experience. This is not to say that the proposed new features don't have technical merit. I thought individually they all were quite worthy. The problem comes more in the area of "marketing." Collectively do the new features make up for the burden of implementation and learning curve by making the language more popular? If the answer is "no," then we need to ask ourselves what is the point if the revision endeavor. Moving forward, I think we should be able to vote for or against individual features. In general I think 5.97 needs more discussion. My recommendation is to take in the feedback provided during the balloting processor, write a 5.98, and have a new vote.