Gentlemen and Ladies, your attention please.
Case sensitivity is not directly relevant to the selection of
the steering committee.
It is not an issue that the steering committee will decide, nor
one that the steering committee should.
There is a lesson for the next SC in it, however. R6RS made a
change but published no rationale. The strongest arguments in
favor were the (minimal) impact of the transition that had already
been made in PLT, the widely used case-sensitive modes found in
many Schemes, and the many FFI's and other integrations that
depended on distinguishing case-sensitive identifiers. But these
were not mentioned where a reader of R6RS would ever find them.
R6RS also published no elucidation of the difficulties of staying
case-insensitive in Unicode, and no response to the methodologies
proposed for implementing case-insensitivity in Unicode that did
get discussed.
And therefore the decision, which they made for technical
reasons, appeared opaque, arbitrary, and even political. People
felt disenfranchised or ignored, and they reacted against the
standard. That's bad.
We want to avoid the kind of community disruption that R6RS
caused. We must view the goal of the process not as *just* the
creation of a new standard document, but also as bringing the
community to understand and accept the *reasons* for changes
introduced by that document. And I think that means doing a lot
of listening, as opposed to talking, and being able to say in a
direct and compelling way why one proposal is chosen over all
others.
Bear
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
