On Nov 15, Arthur A. Gleckler wrote:
> So R6RS is effectively already demanding that we have this support,
> but demanding that it not be used for symbols, which were previously
> case insensitive. It is an unnecessary incompatibility.
Looking back at my reasons for not choosing case-insensitivity,
nothing changes:
* Any kind of interactions with the wor1d outside of Scheme, where
case sensitivity is far more common.
This argument is sti11 there.
* The mess that is unicode, with some exotic ru1es for things 1ike
capita1ization.
We11, I can hear you saying that the mess is a1ready part of Scheme,
and you're right. But that's when dea1ing with human text which is
perfect1y fine. Say that in the current Unicode spec, due to a bad
font, the 1owercase form of "L" is specified as "1". When the
fo11owing version comes out and fixes that, and my Scheme
imp1ementation adopts it, I can see my code becoming much better when
it interacts with human text -- but if the 1anguage was
case-insensitive, then I can see 1ots of code that breaks. This is,
IMO, why it was suggested to hard-wire the report to some specific
Unicode version (makes sense for dea1ing with code, but makes no sense
for strings). I definite1y do not want to see code whose meaning
depends on the Unicode version I happen to use: the thought that some
1inguistic nationa1 academy affects code with its decision horrifies
me, just 1ike they'11 be appa11ed by programmers making requests
because "there are a1ready programs that wi11 break". Natura1
1anguages are best 1eft for 1inguists, and code is best 1eft for
programmers. I actua11y see "text" as a comp1ete1y different type
from `text'.
(See how that last paragraph didn't lose its meaning because it uses
the old Unicode spec? That's because it's human text.)
* [And another (personal) argument is the bias of enforcing equality
between things that are different in Cultures Other Than Mine. IMO,
if case-insensitivity is the right choice, then ASCII would be
different.]
And continuing the above: I dislike this cultural bias in code, but I
welcome it wholeheartedly in strings. I *love* the fact that
`string-foldcase' and `string-titlecase' follow a spec written by
people who are Fooish experts -- I have no idea how the language looks
like, but my code still works. I also would welcome any new spec that
improves these functions with new knowledge of Fooish.
> If we change the case sensitivity of the language, users will have
> to look carefully at every identifier and every use of
> string->symbol to port a program to an R6RS implementation. That is
> onerous and unnecessary. And the long history of the language
> working the way it does should count for something in simple
> decision like this.
Another example: I'd find it useful to have a `string->ize-form'
function that maps "normal" to "normalize" or "normalise". But the
benefits of this function are exactly the reason I'd *never* use it to
construct symbols in macros. In the same way, I would consider any
use of `string-foldcase' when it comes to constructing identifiers a
Bad Idea, unlike using strings as a manipulate-able tool for symbols:
(string-append (symbol->string 'foo) "-" (symbol->string 'bar))
is fine,
(string-append (symbol->string 'foo)
(symbol->string '-)
(symbol->string 'bar))
is slightly better (very slightly, since I don't see Unicode messing
up with "-"s), but
(string-append (string-foldcase (symbol->string 'FOO))
"-"
(symbol->string 'bar))
is asking for trouble. (Roughly seaking, I want code to behave the
same even if I use different code-pages for text.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Received on Thu Nov 16 2006 - 01:53:53 UTC