Symbol case folding is not only a matter of the reader but
also affects the writer if we want to guarantee write-read
invariance. In Common Lisp, they are unified; both are
controlled by the value of readtable-case slot of the current
readtable. If we want R6RS to support both modes, we need a
dynamic scoped parameter that specifies the mode.
This still causes surprises when persistent data is
written in one mode and then read in another. That's why
I prefer "R5RS compatibility reader", which just allows
to *use* legacy code but handles everything else in case-
sensitive manner. But I can live with the dynamic mode.
(And remember, no matter how large your current code base is,
we have to assume there will be more code to be written,
and mostly by people younger than us, who are used to
case-sensitive languages).
--shiro
From: Chris Hanson <cph_at_csail.mit.edu>
Subject: [r6rs-discuss] Scheme should not be changed to be case sensitive
Date: Thu, 16 Nov 2006 02:42:29 -0500
> As someone who has quite a bit of "legacy" Scheme code (about half a
> million lines), I'm really unhappy about the suggestion that the
> language be made case sensitive. This _despite_ the fact that nearly
> all of my current work is based on XML and RDF, where case sensitivity
> is a bonus.
>
> I'd like to suggest a compromise: R6RS requires implementations to
> provide both case-sensitive and case-insensitive interning of symbols,
> but provides a notation to specify which is to be used. In the
> absence of any such notation, the default would be implementation
> specific. This provides for portability of new code, which would be
> marked to indicate its preference. It also provides for backwards
> compatibility for the large body of older code.
>
> I have two suggestions for a notation. The one I prefer is a pair of
> reader tokens #!fold-case and #!no-fold-case which cause the reader to
> change its interning mode. (The reader tokens themselves should
> probably be case sensitive.) This notation has two advantages: (1)
> it's a simple and direct statement of the programmer's intent, and (2)
> it allows files with mixed case sensitivity. (Some readers may
> disagree that point (2) is an advantage, but I don't want to quibble
> about that; point (1) is sufficient.)
>
> An alternative is to bind the notation into the module system somehow.
> Since the module system is responsible for providing meaning to the
> names in a program, this is not that much of a stretch. An advantage
> of this notation is that the module system's structure might help to
> minimize the amount of notation required. However I'm reluctant to
> bind this functionality into the module system, particularly since
> modules aren't yet that well understood.
>
> Whatever is chosen, I _also_ favor the use of |...| syntax to override
> the behavior for a single symbol. (And of course I think that foo and
> |foo| should be eq.) This syntax has the additional _major_ advantage
> that it gives a standard external representation for all symbols.
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
Received on Thu Nov 16 2006 - 03:21:28 UTC