Hey Andrew, On 23-Feb-2009 Andrew Reilly wrote: > On Sat, Feb 21, 2009 at 09:03:30PM -0800, Guillermo J. Rozas wrote: >> - The great inconvenience and lack of respect for existing users >> which the change causes/caused. Even though I much prefer case >> insensitivity, I would not argue for C to change. It would be >> too disruptive. >> Why are Scheme users afforded any less consideration? > > This is the bit that I don't understand. I thought that the > argument for case-insensitivity was to prevent (presumably > 'other') programmers from using symbols that differ only incase, > because that would be confusing.
The argument I take is that Scheme has always been Case Insensitive, and that there is no real need to change this (it is technicaly feasible to keep it in, even if it is a little annoying from an internationalization standpoint), SO *don't*. That is, changing it doesn't give us any technical improvement that is good enough to warrant breaking backwards compatibility. I hold backwards compatibility pretty strongly, and while I am not opposed to breaking it for good reason, I am not sure there is really a good reason here. > So it follows that good, existing code does *not* use symbols that > differ only in case, because that would be confusing. So from the > point of view of existing code, case-sensitive or case-insensitive > ought not to matter. > > Are there any existing scheme style guides that advocate specific > change of symbol case for any particular purpose? All of the scheme > that I've read to date has, I think, had universally lower-case > identifiers. There is a common practice to use differences of case in order to emphasis or elucidate parts of your code. This is made possible by case insensitivity. I often see this style when dealing with Macro defintiions and the like. In fact, when doing some porting of R5RS code to R6RS systems without #!case-fold, I found this to be VERY annoying. It is the same reason that I use the convention of putting procedures in ALL CAPS when discussing them in line with my normal text. It's easier to do this than to have to delimit everything with annoying quotes. Stylistically, I think its nice to be able to change the case when its appropriate and still reference the same procedure, without having to litter your code with double definitions. At the end of the day however, Languages work both ways, both case sensitively and case insensitively, and since they both work, we should stick with the one which provides the most backwards compatibility with previous versions of Scheme. We shouldn't unnecessarily tie down the core language or its character sets and so forth in such a way that we get attached to one character set or the other, but in the same sense, we shouldn't break the backwards compatibility so readily either, and especially since this is such a cosmetic difference. This was the major failing of R6RS, and something that the Scheme Committee should focus on: how important is backwards compatibility? I think it's very important, and that we should try to rectify the backwards compatibility issues that were introduced in R6RS, and see if there is a way of moving forward more smoothly, though moving forward sometimes means introducing some well justified breaks in backwards compatibility. No, I don't think Case Sensitivity counts as moving the language forward much at all. -- Aaron W. Hsu <[email protected]> | <http://www.sacrideo.us> "Government is the great fiction, through which everybody endeavors to live at the expense of everybody else." -- Frederic Bastiat +++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
