Hi Aaron, On Sun, Feb 22, 2009 at 09:55:28PM -0500, Aaron W. Hsu wrote: > 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.
OK, I can see how that sort of convention could grow up when you're used to a case-insensitive language. Better than being case sensitive with case that you hate, IMO (keywords in all-caps in Modula-x spring to mind... ) These days we mostly rely on our editor environment to provide colour and font decoration for emphasis and legibility, I suppose. > 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. Maybe in the next version we could get completely out of the box and allow source code to be encoded in HTML or RTF, to allow semantically-transparent emphasis, with font, font-size and colour? Would there be a move at some future stage to insist on some particular font in some context? I would hope not. I understand that there are dialects of Forth in which colour is significant. It'd be kind of cool to be able to use an italic-i as in index variable, for instance. I suppose that that level of decoration is completely possible by using one of the various literate programming preprocessors though, completely independently of the language definition process. > 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. Sometimes (always?) changes break some things. Even the well-known heroically backwards-compatible like C wind up introducing the odd new keyword that shadows a variable name, or tightened semantics that makes old code break (C had lots of ways to do that, of course). One of the ways that this is usually accommodated is for the compilation/execution environments to have explicit backwards compatability modes. Compile with this switch and your source code must be to standard XX.Y, with the default or some other switch to standard YY.Z. The execution environment then generally manages to let you link those old, working pieces of code into new pieces coded to the new standard. Code that continues to be relevant and worked-on generally gets updated to comply with the new standard, but it doesn't have to happen straight away, or all at once. I think (as a user, not an implementor) that this is a better way of maintaining backward compatability than tying the language spec down with the requirement that all arbitrarily old programs must continue to run. That cuts out a lot of options. [I'd give the example of PLT's language system here except that the switch to immutable cons cells seems to make such cross-language-version integration harder than necessary.] [I will mention the fact that the FreeBSD operating system maintainers are considering switching the code's language standard from gnu89 to gnu99, something which affects most code files not at all, but there are some exceptions, and it seems that they can be accommodated.] Cheers, -- Andrew _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
